1.Kafka 问题清单.md



Kafka使用场景

  1. 消息（P2P，订阅消费）
  2. 网站活动追踪（高吞吐，实时性）
  3. 日志聚合（ELK，代替L，实时性）
  4. 流处理（Kafka Stream，实时性）
  5. 事件采集（空间大）
  6. 提交日志（压缩功能）

为什么出现kafka?kafka的架构是怎么演进的

kafka为什么性能快

  1. 消息集合在一起，这样减少网络请求的往返，而不是一次发送单个消息。
  2. 将随机消息写入的突发流转换成流向消费者的线性写入。
  3. 采用由生产者，经纪人和消费者共享的标准化二进制消息格式（样数据块就可以在它们之间自由传输，无需转换）。
  4. 使用sendfile，：允许操作系统将数据直接从页缓存发送到网络上
  5. 端到端的批量压缩,通过递归消息集来支持这一点。 一批消息可以一起压缩并以此形式发送到服务器。 这批消息将以压缩形式写入，并将在日志中保持压缩，并且只能由消费者解压缩。

kafka 小消息高并发，大消息低并发

kafka 怎么解决软件的复杂度的?(性能、可靠、扩展、规模、安全)

kafka 各个版本之间在差异和升级注意事项

Exactly Once语义与事务机制原理

Kafka Producer高可用和配置优化

Kafka Consumer高可用和配置优化

Kafka 消息大小参数设置

broker：
message.max.bytes = 1048576 
replica.fetch.max.bytes = 1048576

producer：
max.request.size = 1048576
consumer：
#old consumer
fetch.message.max.bytes = 1048576 
#new consumer
max.partition.fetch.bytes = 1048576

Kafka 顺序消息怎么设计？

只有一个partition，飞行消息设为最大1

Kafka 用到的数据结构

  • 双端队列
  • 时间轮
  • 延迟队列

Kafka 消息幂等怎么设计？

直接开启幂等，数据库或者支持主机的存储系统

Kafka broker高可用和配置优化

kafka 集群规模

kafka Stream设计与实现、优缺点

Kafka性能测试方法及Benchmark报告

kafka怎么避免集群发生脑裂

kafka扩容机制

kafka运维平台怎么构建

2.Kafka 资料.md

kafka压缩测试

技术世界

芋道源码

ORCHOME

优酷kafka视频

Kafka的“真面目”

图解 Kafka 之实战指南

Kafka -- 内部原理

Kafka水位(high watermark)与leader epoch的讨论

PhxQueue

kafka如何扩容服务器、重新分区Partition

3.Kafka 不同版本差异.md

Kafka 目前总共演进了 7 个大版本，分别是 0.7、0.8、0.9、0.10、0.11、1.0 和 2.0，其中的小版本和 Patch 版本很多

尽量保持服务器端版本和客户端版本一致，否则你将损失很多 Kafka 为你提供的性能优化收益。

1.0/2.0

最后我合并说下 1.0 和 2.0 版本吧，因为在我看来这两个大版本主要还是 Kafka Streams的各种改进，在消息引擎方面并未引入太多的重大功能特性。Kafka Streams 的确在这两个版本有着非常大的变化，也必须承认 Kafka Streams 目前依然还在积极地发展着。如果你是 Kafka Streams 的用户，至少选择 2.0.0 版本吧。

0.11

幂等和事务是Kafka 0.11.0.0版本引入的两个特性，以此来实现EOS（exactly once semantics，精确一次处理语义）。
幂等，简单地说就是对接口的多次调用所产生的结果和调用一次是一致的。生产者在进行重试的时候有可能会重复写入消息，而使用Kafka的幂等性功能之后就可以避免这种情况。

0.10

0.10.0.0 是里程碑式的大版本，因为该版本引入了 Kafka Streams。

参考资料

https://segmentfault.com/a/1190000021725811

4.Kafka 日志索引.md

查看索引内容：

bin/kafka-dump-log.sh --files /tmp/kafka-logs/ topic-log-0/00000000000000000000.index

偏移量索引项的格式如下图所示。每个索引项占用8个字节，分为两个部分。

relativeOffset：相对偏移量，表示消息相对于 baseOffset 的偏移量，占用4个字节，当前索引文件的文件名即为 baseOffset 的值。
position：物理地址，也就是消息在日志分段文件中对应的物理位置，占用4个字节。

Kafka 的每个日志对象中使用了 ConcurrentSkipListMap 来保存各个日志分段，每个日志分段的 baseOffset 作为 key，这样可以根据指定偏移量来快速定位到消息所在的日志分段。

时间戳索引项的格式如下图所示。
每个索引项占用12个字节，分为两个部分。

timestamp：当前日志分段最大的时间戳。
relativeOffset：时间戳所对应的消息的相对偏移量。

5.kafka原理解析.md

kafka为什么快

Kafka总结
总的来说Kafka快的原因：
1、partition顺序读写，充分利用磁盘特性，这是基础；
2、Producer生产的数据持久化到broker，采用mmap文件映射，实现顺序的快速写入；
3、Customer从broker读取数据，采用sendfile，将磁盘文件读到OS内核缓冲区后，直接转到socket buffer进行网络发送。

mmap 和 sendfile总结
1、都是Linux内核提供、实现零拷贝的API；
2、sendfile 是将读到内核空间的数据，转到socket buffer，进行网络发送；
3、mmap将磁盘文件映射到内存，支持读和写，对内存的操作会反映在磁盘文件上。
RocketMQ 在消费消息时，使用了 mmap。kafka 使用了 sendFile。

参考：https://zhuanlan.zhihu.com/p/78335525

Kafka幂等性原理及实现剖析

Producer在生产发送消息时，难免会重复发送消息。Producer进行retry时会产生重试机制，发生消息重复发送。而引入幂等性后，重复发送只会生成一条有效的消息。Kafka作为分布式消息系统，它的使用场景常见与分布式系统中，比如消息推送系统、业务平台系统（如物流平台、银行结算平台等）。以银行结算平台来说，业务方作为上游把数据上报到银行结算平台，如果一份数据被计算、处理多次，那么产生的影响会很严重。

Kafka为了实现幂等性，它在底层设计架构中引入了ProducerID和SequenceNumber。那这两个概念的用途是什么呢？

ProducerID：在每个新的Producer初始化时，会被分配一个唯一的ProducerID，这个ProducerID对客户端使用者是不可见的。
SequenceNumber：对于每个ProducerID，Producer发送数据的每个Topic和Partition都对应一个从0开始单调递增的SequenceNumber值。

produceid 默认是进程pid

参考：https://www.cnblogs.com/smartloli/p/11922639.html

6.kafka cmd.md

模拟消费

bin/kafka-console-consumer.sh --topic soa-detail-local --bootstrap-server ?:9092

Copyright © 2018 INSTALL.REN