smart_an的专栏

本章，我对GroupCoordinator协调器的底层原理进行了讲解。Kafka Consumer的核心无非就是三块：分区分配、offset管理、底层通信。分区分配的核心就是GroupCoordinator，底层通信的原理和Producer类似，offset管理主要涉及HW、LEO。至此，整个Kafka源码分析系列我就讲完了，剩余的很多边边角角的内容和细节读者可以自己去研读源码。

本章，我对Kafka的分区重分配流程和底层实现原理进行了讲解，分区重分配本质在于数据复制，先增加新的副本，然后进行数据同步，最后删除旧的副本来达到最终目的。数据复制会占用额外的资源，所以，分区重分配一定要在低峰值时期执行。另外，可以减小重分配的粒度，以小批次的方式来操作是一种可行的解决思路。但是，如果集群中某个分区的流量即使在低峰时期还是特别大，那么就需要采取限流机制，Kafka默认提供了两种复制限流的方式：通过脚本和实现。我就不赘述了，读者可以找相关资料了解。

本章，我对Topic创建的整体流程和底层原理进行了讲解，Controller会监听新Topic的创建，同时对分区副本进行管理，向新的元数据信息发送给集群中的其它Broker。

本章，我对Kafka的Broker集群的选举流程进行了讲解，Kafka Server服务启动后，每个Broker内部都包含一个KafkaController组件，选举流程的本质就是通过该组件往Zookeeper写入节点，首先写入成功的就是Leader，即Controller。Controller负责管理整个Broker集群，包含Broker的上下线感知，分区副本的分配、选举，集群元数据的通知更新等等。下一章，我就来讲解。

本章，我对副本同步中的最后一块内容——延迟读写进行了讲解。Kafka就是利用了时间轮机制对这种延迟读写的情况进行处理。

Leader侧的消息读取流程；Leader侧的LEO和HW维护；Leader侧的ISR列表维护；

本章，我站在Follower副本的角度对副本同步的整个流程进行了讲解。Broker启动后，会在创建多个后台线程——，负责副本的同步。ReplicaFetcherThread是按照Broker维度创建的，一批Leader分区在同一个Broker上的Follower分区共用一个ReplicaFetcherThread；ReplicaFetcherThread拉取消息时，本质还是作为Producer发送请求，走的还是Kafka自定义的一套NIO通信框架；Follower拉取到消息后，按照日志子系统。

本章，我对Kafka中的索引进行了深入讲解。这是 Kafka 所有类型索引的抽象父类，里面的 mmap 变量是实现索引机制的核心，Kakfa采用了内存映射文件实现了索引的写入，极大提升了IO性能；Kafka对二分查找算法进行了改进，将所有索引项分成两个部分：热区（Warm Area）和冷区（Cold Area），然后分别在这两个区域内执行二分查找算法，从而提升页缓存的使用率，避免缺页中断（Page Fault）问题。

本章，我对LogSegment这个分段日志对象进行了讲解，我们需要重点关注它的append方法，也就是写日志的方法。LogSegment会判断每写入4KB消息，就写入一个稀疏索引。

本章，我对Log对象进行了简单的讲解。Log是LogSegment日志段的容器，里面定义了很多管理日志段的操作，我们目前只需要关注它的写日志方法即可。

本章，我带大家回顾了Kafka的日志结构，然后对Log Subsystem的核心组件进行了整体分析，并找到了日志写入的入口，分析了日志写入的整体流程。下一章开始，我将逐一分析日志写入过程中涉及的各个核心组件。

KafkaApis的整体结构是非常清晰的，本章我就不过多展开了，读者完全可以自己打开KafkaApis.scala的源码去看下它的具体功能。

本章，我对网络层的最后两个组件RequestChannel和RequestHandler进行了讲解。它们的整体设计思路还是比较清晰简单的，本质就是利用不用的内存队列和线程池对请求/响应进行处理，提升整体吞吐量，这种思路在实际的生产应用中运用非常多，我在《分布式系统从理论到实战系列》专栏的实战篇中也讲解过这类运用，感兴趣的读者可以去看一看。

本章，我对Processor线程的整体架构以及它对读写请求的处理流程进行了详尽的分析，我们需要重要了解：KafkaChannel只能交替处理读写请求。下一章，我将对RequestChannel这个核心组件进行讲解。

本章，我对Kafka Server的Network Layer网络层的整体架构和Acceptor线程对请求的处理流程进行讲解。Acceptor线程其实只是监听指定端口的请求连接，然后完成连接的建立，并将连接对应的SocketChannel转交给Processor线程处理。下一章，我会对Processor线程的工作线程和底层源码进行分析。

本章，我对Broker的整体架构以及启动流程进行了讲解，Kafka Broker从整体上分为四个模块：Network Layer（网络层）、API Layer（API层）、Log Subsystem（日志子系统）、Replication SubSystem（副本子系统）。下一章开始，我将先对Network Layer（网络层）的底层源码进行分析。

本章，我对KafkaProducer发送消息的过程中可能会出现的消息超时请求积压在BufferPool；请求积压在InFlightRequests。无论哪种情况，请求超时的判断逻辑中都涉及参数，默认超时时间为60s。同时，超时后最终会触发回调函数的执行。

本章，我对Kafka客户端处理响应的流程和底层原理进行了详细分析，读者需要关注的重点是Kafka客户端是如何对响应的拆包和粘包问题进行处理的，以及解析完响应内容后的后续处理流程，包含回调、异常、缓冲区处理等等。Kafka客户端的KafkaChannel缓存了最近读取响应的NetworkReceive对象，只要一个完整的请求没有全部读取完，就不会移除对该响应的缓存。

本章，我对Kafka客户端对消息发送的“拆包”处理的底层原理进行了讲解。对每一个Broker要发送的消息，封装成一个NetworkSend请求，请求包含两部分：请求头和请求体，请求头共4字节，标识着请求体的大小；Kafka通过计算NetworkSend请求的remaining字段——待发送字节数，判断是否发送完了所有数据；

本章，我对Sender线程Loop循环处理的最后一步——Selector轮询处理进行了讲解，这也是最核心的一步。Kafka客户端对于请求的处理，完全是NIO模式，Sender线程对请求的异步处理机制，也非常值得我们借鉴学习。到本章为止，Kafka客户端的消息发送的整体流程我就已经全部分析完了，底层NIO组件的工作机制也已经初步做了分析。从下一章开始，我将深入讲解Kafka底层NIO通讯组件的工作原理，包含对“粘包”和”拆包“的处理、异常处理等等。

本章，我对Sender线程Loop执行过程中创建ClientReqeust对象并“发送”的底层原理进行了讲解，核心流程可以用下面这张图总结：可以看到，Kafka客户端的所有网络通信请求都是通过NIO进行的，并不是真正发送网络请求，而是封装请求对象并缓存到InFlightRequests，同时将请求提交到发送连接对应的KafkaChannel中。Selector会监听各个Channel的OP_WRITE事件，那么当后续Sender线程执行。

本章，我对客户端检查Broker连接状态的底层原理进行了讲解，核心思路就是检查当前客户端与哪些待筛选的Broker还没有建立TCP长连接，如果没有建立连接，Kafka Producer就会在底层通过Java NIO的封装组件尝试建立连接。

本章，我对Sender线程Loop处理流程中，就绪Batch消息筛选的底层原理进行了讲解。我们需要主要关注的是，在哪些情况下，缓冲区中的消息会被立马发送。

本章，我对RecordAccumulator的内存结构和消息缓存的底层原理进行了讲解。RecordAccumulator会按照分区维度将消息缓存，底层采用了一个CopyOnWriteMap来保存这种映射关系；RecordAccumulator会将多个消息打成一个RecordBatch，目的是后续Sender线程可以按批次发送消息，减少网络传输的开销，提升整体吞吐量；

本章，我对KafkaProducer的分区器的内部原理进行了讲解。如果我们指定了消息的Key，那么同一个Key的不同消息，会生成相同的hash值，路由到的分区也一定是相同的。但是需要特别注意，如果对主题的分区进行了增减，那么就难以保证 key 与分区之间的映射关系了。

本章，我对Producer的Topic元数据拉取机制进行了讲解，Topic的元数据都是按需拉取的，这是一种延迟加载的思想。Sender线程成功的在时间内（默认60秒），把Topic元数据加载到了，然后缓存到了Metadata里去，更新了version版本号，此时会尝试把阻塞等待的主线程唤醒；主线程等待超过60秒，Sender线程还没有完成元数据加载，则抛出超时异常。另外，Sender线程在实际拉取元数据时，会挑选一个负载最小的Broker节点，然后向这个 节点发送请求来获取具体的元数据信息。

本章，我对KafkaProdcer的初始化整体流程进行了分析，下一章开始，我将分析KafkaProducer内部的各个核心组件。

本章，我搭建完了Kafka源码分析的环境，读者可以自己启动一个Kafka客户端程序，尝试发送一个消息进行验证。从下一章开始，我们正式进入Kafka源码分析环节。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！讲解完了Kafka的各个组件的核心工作原理，接下来的章节我会通过一个实际生产案例介绍Kafka的使用，我们先来看下整个案例的背景。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！Kafka中存在大量的延时操作，比如延时生产、延时拉取和延时删除等。Kafka并没有使用JDK 自带的 Timer 或 DelayQueue 来实现延时的功能，而是基于的概念实现了一个用于延时功能的定时器（ SystemTimer ）。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！每个消费者组都会选择一个Broker作为自己的Coordinator，这个GroupCoordinator协调器负责监控这个消费组里的各个消费者的心跳，判断它们是否宕机，如果宕机则进行Rebalance。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！了解了Kafka的生产者基本原理后，本章，我将讲解Consumer消费者的基本原理，通过本章的内容，读者可以理解一条消息从获取到被消费的整个流程。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！了解了Kafka的整体架构之后，我将站在客户端的角度对Kafka的生产者（Producer）和消费者（Consumer）进行讲解。本章，我们先从Producer开始，我将讲解Producer的基本原理，通过本章的内容，读者可以理解一条消息从生产到发送的整个流程。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！Kafka集群启动时，会自动选举出一个Broker，承担Controller的责任。所谓Controller，就是Kafka集群的一个总控组件，负责管理整个集群，包括Leader Partition选举、分区负载均衡、管理集群元数据等等。那么，本章我们就来看看，Controller的核心工作机制。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！Kafka Broker基于Reactor模式，通过I/O多路复用来完成请求的处理，所以具有极高的吞吐量。关于I/O多路复用，我在其它的专栏里反复讲解过多次了。本章，我再来针对Kafka讲解下它是如何实现多路复用的。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！我在这一章中，已经比较清楚的介绍了Kafka的ISR机制。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！Kafka具有的特性。那么Kafka是如何实现的呢？这就涉及到消息的持久化机制了。Kafka会将消息追加到分区日志文件中，并且仅仅是追加数据到文件末尾，也就是采用了的机制。但是，光顺序写其实还是不够的，Kafka同时利用了操作系统的Page Cache，也就是说消息不是写到磁盘上，而是写到缓存中，正是依靠了。

作者简介：大家好，我是哥，前中兴通讯、美团架构师，现某互联网公司联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬学习必须往深处挖，挖的越深，基础越扎实！Kafka可以对消息进行存储，写消息的本质就是写日志文件。在Kafka中，主题的一个分区，在操作系统层面就对应着一个目录，命名形式为。本章，我就来讲解Kafka中的日志格式。

本章，我先从整体上对Kafka的核心功能和架构进行了分析，从后续章节开始，我将对Kafka每一个组件进行深入剖析。