kafka学习笔记-CSDN博客

在消息发送的过程中，涉及到了两个线程——main线程和Sender线程。在main线程中创建了一个双端队列RecordAccumulator。main线程将消息发送给RecordAccumulator，Sender线程不断从RecordAccumulator中拉取消息发送到KafkaBroker。

生产者重要参数配置

kafka分区的好处

kafka生产者发送消息分区策略

生产者如何提高吞吐量

如何保证发送数据的可靠性

数据完全可靠条件 = ACK 级别设置为 -1 + 分区副本大于等于 2 + ISR 里应答的最小副本数量大于等于 2

可靠性总结：

acks=0 ，生产者发送过来数据就不管了，可靠性差，效率高；

acks=1 ，生产者发送过来数据 Leader 应答，可靠性中等，效率中等；

acks=-1 ，生产者发送过来数据 Leader 和 ISR 队列里面所有 Follwer 应答，可靠性高，效率低；

在生产环境中， acks=0 很少使用； acks=1 ，一般用于传输普通日志，允许丢个别数据； acks=-1 ，一般用于传输和钱相关的数据，

对可靠性要求比较高的场景。

如何保证数据不重复（幂等性和事务）

如何保证数据有序

2、broker

Zookeeper 存储的 Kafka信息

ZooKeeper 为 Kafka 提供了元数据的管理，例如一些 Broker 的信息、主题数据、分区数据等等。

__consumer_offsets 内置topic里面采用 key 和 value 的方式存储数据。key 是 group.id+topic+ 分区号，value 就是当前 offset 的值。每隔一段时间，kafka 内部会对这个 topic 进行 compact，也就是每个 group.id+topic+分区号就保留最新数据。

Kafka Broker总体工作流程

第一步：broker启动后在zk中注册，争抢controller
第二步：谁先注册Controller，谁说了算
第三步：由选举出来的Controller，监听brokers节点变化
第四步：Controller决定Leader选举
第五步：Controller将节点信息上传到ZK
第六步：其他contorller从zk同步相关信息，万一挂了他们好上位
第七步：假设Broker1中Leader挂了
第八步：Controller监听到节点变化
第九步：获取ISR
第十步：选举新的Leader（在 isr中存活为前提，按照 AR中排在前面的优先）
第十一步：更新Leader及ISR

broker重要参数

副本基本信息

（1）Kafka 副本作用：提高数据可靠性。

（2）Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会

增加磁盘存储空间，增加网络上数据传输，降低效率。

（3）Kafka 中副本分为：Leader 和 Follower。Kafka 生产者只会把数据发往 Leader，

然后 Follower 找 Leader 进行同步数据。

（4）Kafka 分区中的所有副本统称为 AR（Assigned Repllicas）。

AR = ISR + OSR

ISR，表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms参数设定，默认 30s。Leader 发生故障之后，就会从 ISR 中选举新的 Leader。

OSR，表示 Follower 与 Leader 副本同步时，延迟过多的副本。

Leader选举流程

Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader ，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。

Controller 的信息同步工作是依赖于 Zookeeper 的。

第一步：broker启动后在zk中注册，争抢controller
第二步：谁先注册Controller，谁说了算
第三步：由选举出来的Controller，监听brokers节点变化
第四步：Controller决定Leader选举
第五步：Controller将节点信息上传到ZK
第六步：其他contorller从zk同步相关信息，万一挂了他们好上位
第七步：假设Broker1中Leader挂了
第八步：Controller监听到节点变化
第九步：获取ISR
第十步：选举新的Leader（在 isr中存活为前提，按照 AR中排在前面的优先）
第十一步：更新Leader及ISR

Leader 和 Follower 故障处理细节

Leader Partition 负载平衡

kafka数据文件存储

index中只存offer的相对位置，而且是每4kb的log文件才存一条索引数据，这种方式叫做稀疏索引。
相对索引的含义是相对于自己的文件名（文件名是第一条索引）的位置，如上图，相对索引为65，那么65+自己文件名522，就是真实的offset的位置587。
然后根据index计算出来的结果去log中寻找对应的数据即可。

文件清理策略

Kafka 中提供了2种日志清理策略： delete 和 compact

delete ：将过期数据删除，这里又有2种删除方式，一种是按照时间删除，一种是按照大小删除，所谓时间删除，是将超过保留时间的数据删除，这里的删除单位是segment，时间是以 segment 中所有记录中的最大时间戳作为该文件时间戳。只看最大时间，还有一种是按照大小，超过多少大小的日志后，将前面的日志删除（按照大小删除不常用）

compact日志压缩：这里的压缩是指将消息队列中相同key的数据只保留最新的数据，而不是使用某种方式将数据进行压缩。这种策略只适合特殊场景，比如消息的key是用户ID，value是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。

kafka高效读写数据的原理

1）Kafka 本身是分布式集群，可以采用分区技术，并行度高

2）读数据采用稀疏索引，可以快速定位要消费的数据

3）顺序写磁盘

Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

4）页缓存 + 零拷贝技术

零拷贝技术：减少用户态/内核态的切换次数以及CPU拷贝的次数

看一遍就理解：零拷贝原理详解 - 知乎

3、消费者

kafka消费模式

消费者工作流程

消费者组原理

消费者组初始化流程

消费者组详细消费流程

消费者重要参数配置

分区的分配与再平衡

注意：新版本的session.timeout.ms （默认值为10s）

「（重平衡）Rebalance本质上是一种协议，规定了一个Consumer Group下的所有Consumer如何达成一致，来分配订阅Topic的每个分区」。

比如某个Group下有20个Consumer实例，它订阅了一个具有100个分区的Topic。

正常情况下，Kafka平均会为每个Consumer分配5个分区。这个分配的过程就叫Rebalance。

「Rebalance的触发条件有3个。」

组成员数发生变更。比如有新的Consumer实例加入组或者离开组，或是有Consumer实例崩溃被踢出组。
订阅主题数发生变更。Consumer Group可以使用正则表达式的方式订阅主题，比如consumer.subscribe(Pattern.compile(“t.*c”))就表明该Group订阅所有以字母t开头、字母c结尾的主题，在Consumer Group的运行过程中，你新创建了一个满足这样条件的主题，那么该Group就会发生Rebalance。
订阅主题的分区数发生变更。Kafka当前只能允许增加一个主题的分区数，当分区数增加时，就会触发订阅该主题的所有Group开启Rebalance。

Rebalance发生时，Group下所有的Consumer实例都会协调在一起共同参与。

「分配策略」

当前Kafka默认提供了3种分配策略，每种策略都有一定的优势和劣势，社区会不断地完善这些策略，保证提供最公平的分配策略，即每个Consumer实例都能够得到较为平均的分区数。

比如一个Group内有10个Consumer实例，要消费100个分区，理想的分配策略自然是每个实例平均得到10个分区。

这就叫公平的分配策略。

举个简单的例子来说明一下Consumer Group发生Rebalance的过程。

假设目前某个Consumer Group下有两个Consumer，比如A和B，当第三个成员C加入时，Kafka会触发Rebalance，并根据默认的分配策略重新为A、B和C分配分区

Rebalance之后的分配依然是公平的，即每个Consumer实例都获得了2个分区的消费权。

在Rebalance过程中，所有Consumer实例都会停止消费，等待Rebalance完成，这是Rebalance为人诟病的一个方面。

目前Rebalance的设计是所有Consumer实例共同参与，全部重新分配所有分区。

「Coordinator会在什么情况下认为某个Consumer实例已挂从而要退组呢？」

当Consumer Group完成Rebalance之后，每个Consumer实例都会定期地向Coordinator发送心跳请求，表明它还存活着。

如果某个Consumer实例不能及时地发送这些心跳请求，Coordinator就会认为该Consumer已经死了，从而将其从Group中移除，然后开启新一轮Rebalance。

Consumer端有个参数，叫session.timeout.ms（默认10s）。

该参数的默认值是10秒，即如果Coordinator在10秒之内没有收到Group下某Consumer实例的心跳，它就会认为这个Consumer实例已经挂了。

除了这个参数，Consumer还提供了一个允许你控制发送心跳请求频率的参数，就是heartbeat.interval.ms（默认3s）。

这个值设置得越小，Consumer实例发送心跳请求的频率就越高。

频繁地发送心跳请求会额外消耗带宽资源，但好处是能够更加快速地知晓当前是否开启Rebalance，因为，目前Coordinator通知各个Consumer实例开启Rebalance的方法，就是将REBALANCE_NEEDED标志封装进心跳请求的响应体中。

除了以上两个参数，Consumer端还有一个参数，用于控制Consumer实际消费能力对Rebalance的影响，即max.poll.interval.ms（默认5min）参数。

它限定了Consumer端应用程序两次调用poll方法的最大时间间隔。

它的默认值是5分钟，表示你的Consumer程序如果在5分钟之内无法消费完poll方法返回的消息，那么Consumer会主动发起离开组的请求，Coordinator也会开启新一轮Rebalance。

「可避免Rebalance的配置」

第一类Rebalance是因为未能及时发送心跳，导致Consumer被踢出Group而引发的

因此可以设置**「session.timeout.ms和heartbeat.interval.msopen in new window」**的值。

设置session.timeout.ms = 6s。
设置heartbeat.interval.ms = 2s。
要保证Consumer实例在被判定为dead之前，能够发送至少3轮的心跳请求，即session.timeout.ms >= 3 * heartbeat.interval.ms。

将session.timeout.ms设置成6s主要是为了让Coordinator能够更快地定位已经挂掉的Consumer。

「第二类Rebalance是Consumer消费时间过长导致的」。

你要为你的业务处理逻辑留下充足的时间，这样Consumer就不会因为处理这些消息的时间太长而引发Rebalance了。

分区策略

offset的维护位置

__consumer_offsets 主题里面采用 key 和 value 的方式存储数据。 key 是 group.id+topic+ 分区号，value 就是当前 offset 的值。每隔一段时间， kafka 内部会对这个 topic 进行 compact，也就是每个 group.id+topic+ 分区号就保留最新数据。

自动提交与手动提交offset

指定offset消费

auto.offset.reset = earliest | latest | none 默认是 latest 。

当 Kafka 中没有初始偏移量（消费者组第一次消费）或服务器上不再存在当前偏移量

时（例如该数据已被删除），该怎么办？

（ 1 ） earliest ：自动将偏移量重置为最早的偏移量， --from-beginning 。

（ 2 ） latest （默认值）：自动将偏移量重置为最新偏移量。

（ 3 ） none ：如果未找到消费者组的先前偏移量，则向消费者抛出异常。

重复消费与漏消费

唯一可能导致消费者弄丢数据的情况，就是说，你消费到了这个消息，然后消费者那边自动提交了 offset，让 Kafka 以为你已经消费好了这个消息，但其实你才刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。

大家都知道 Kafka 会自动提交 offset，那么只要关闭自动提交 offset，在处理完之后自己手动提交 offset，就可以保证数据不会丢。但是此时确实还是可能会有重复消费，比如你刚处理完，还没提交 offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
————————————————