2 Kafka Broker

1. Log的读写、删除流程---日志管理器(log manager)负责创建日志、获取日志、清理日志。所有的日志读写操作都交给具体的日志实例来完成。

KafkaServer启动的时候，初始化三个类：

• LogManager
• SocketServer
• the request handlers - KafkaRequestHandlers

按照顺序组件有：

1. KafkaScheduler
2. LogManager
3. SocketServer
4. ReplicaManager
5. KafkaController
6. GroupCoordinator
7. KafkaApis
8. KafkaRequestHandlerPool
9. KafkaHealthcheck

Tips:

1. KafkaServer启动的时候，用到了数据结构CountDownLatch shutdownLatch: 用作以后KafkaServer stop的时候，等待别的都关闭完成。

// After calling shutdown(), use this API to wait until the shutdown is complete.
def awaitShutdown(): Unit = shutdownLatch.await()

1.2 LogManager startup

1. 遍历所有的日志目录，如果有.kafka_cleanshutdown就说明是干净的shutdown，跳过当前log的recovery
2. 读取recovery-point-offset-checkpoint文件，返回(topic, partition)->offset 映射。其中文件的第一行是版本号，第二行是记录条数，后面是映射内容
3. 计算出log目录和对应的recovery point，并用来初始化Log对象。
4. 清理工作，清理掉.kafka_cleanshutdown
5. 启动三个定时任务，kafka-log-retention, kafka-log-flusher, kafka-recovery-point-checkpoint
   • retention是删除时间过久，体积过大的log文件。
   • flusher是根据时间间隔刷盘，调用FileChannel.force。
   • recovery-point-checkpoint是把内存里的(topic, partition)->offset checkpoint结构刷盘。
6. 启动LogCleaner

1.2.1 一些删除的策略

1. 删除掉.deleted和.cleaned后缀的文件
2. 碰到.swap说明在swap中途server挂掉，这里的swap过程仅仅是一个rename。这种情况对于index的swap直接删除后面从log文件重建，如果是log的swap就先删index再通过rename的方式swap回log
3. 遇到.index索引文件，如果没有对应的.log文件直接删除
4. 通过.log文件生成LogSegment对象，如果没有索引文件就运行LogSegment.recover重建索引
5. 重建索引的过程是以message为单位遍历LogSegment，遍历过程中如果累加的大小超过了index interval就在索引里面记录一下当前消息偏移量(会转化成相对偏移)和.log文件里面的字节为单位的位置。这个过程中会顺便把log文件和index文件末尾的可能因为crash产生的多余的字节给清理掉。
6. 开始根据recovery point做恢复，这里碰到cleanShutdown文件就会跳过恢复
7. 遍历从recovery point到末尾的LogSegment，调用LogSegment.recover，如果过程中发现多余的字符说明LogSegment非法，就把非法的一直到末尾的全部删掉。
8. 最后对所有的index做一遍sanityCheck

1.2.2 Log.append

1. 参数是MessageSet，一次append一批消息
2. 分析校验，拿到是否递增，压缩codec，以及校验大小，crc，干掉多余的字节
3. 后面的所有过程都加上Log级别的锁，如果需要设置偏移量，就遍历每条消息，设置上偏移量
4. 再做一次消息大小检查，因为前面可能重新压缩过消息
5. 如果当前LogSegment大小加上要append的大小超过上限就滚动到新的segment
6. 用当前Log的logEndOffset生成新的log file和index file，之前的末尾index文件做一下裁剪
7. 用新的log file和index file生成新的LogSegment并加入Log里面的列表，并且把recoveryPoint到之前的logEndOffset的segment加入刷盘队列，刷完了以后recoveryPoint增长到logEndOffset
8. 如果增长的字节量达到了需要做索引的长度就在index里面append一个entry，然后FileMessageSet.append
9. 如果append以后没刷盘的字节过多就刷一下盘

1.2.3 Log.read

1. 参数有一个startOffset，首先定位到offset仅仅比这个低的entry，如果定位不到就直接异常
2. 调用LogSegment.read，首先要找到log文件里面对应startOffset的第一个合法的position
3. 查找过程先通过index查找offset对应的position，查找的过程是标准二分查找，因为用了mmap所以都是在内存里面找。index因为需要经常的随机读和append操作，所以做了mmap
4. 调用FileMessageSet.searchFor，在log文件里找大于offset的合法message的position
5. 用同样的方法计算出end offset对应position，在算出需要读取的字节数
6. 通过这些信息，返回一个FileMessageSet，这里还没有实际读取，后面会提取出byte message返回

1.2.4 LogCleaner

1. 如果对一个消息存在key相同但是offset更高的消息，那么就清理掉这个offset低的消息
2. 先找最脏的Log，找的方法是先读取cleaner-offset-checkpoint里面存了每个log的最后清理offset，然后每个log拿最后清理的offset到active offset所有segments的size和log size算一个比率，然后取比率最大的
3. 开始清理Log，先遍历所有脏的LogSegment，构建一个内存中的OffsetMap(index)，key是消息key，value是消息offset，这个map后面用来判断消息是否是重复的
4. 把所有的LogSegment分个组，每个组的字节大小总量尽量接近于某个指定值。尽量把一个组压缩成一个新的Segment，这样做让新的Segment体积尽量平均
5. 拿出每个组的第一个segment以它的名字创建log和index对应的.cleaned文件
6. 对于组里的每个LogSegment，过滤掉重复的和空的message，其余的全部写入那个新的目标LogSegment
7. 新的LogSegment刷盘，然后把旧的segment list全部删除，最后把.cleaned名字改成.log文件

2.网络协议

看看请求的网络协议里面都存了写什么。

2.1 request and response

1. 首先解析2字节的requestId
2. 根据requestId选择kafka.api包里面对应的request类来处理，序列化反序列化协议 包含在对应的request类里面
3. 有一个correlationId做request和response的关联
4. 拿ProducerRequest做例子

+----------------------------+
|     requestId 2            |
+----------------------------+
|     versionId 2            |
+----------------------------+
|     correlationId 4        |
+----------------------------+
|     clientId               |
+----------------------------+
|     requiredAcks 2         |
+----------------------------+
|     ackTimeoutMs 4         |
+----------------------------+
|     topicCount 4           |
+----------------------------+
| +-------------------------+|
| |   topic                 ||
| +-------------------------+|
| |   partitionCount 4      ||
| +-------------------------+|
| | +----------------------+||
| | | partition 4          |||
| | +----------------------+||
| | | messageSetSize 4     |||
| | +----------------------+||
| | | messageSetContent    |||
| | |                      |||
| | +----------------------+||
| +-------------------------+|
+----------------------------+

message的内容

+--------------+
|CRC 4         |
+--------------+
|Magic 1       |
+--------------+
|attributes 1  |
+--------------+
|key 4         |
+--------------+
|size 4        |
+--------------+
|content       |
+--------------+

第一次创建topic的最后会启动highWaterMark的checkPoint线程，这个线程定期刷所有replica的checkPoint到磁盘。落地在磁盘的文件名叫做：replication-offset-checkpoint

3.partition reassign 扩容的机制

PartitionsReassignedListener监听/admin/reassign_partitions,由KafkaController控制---KafkaController.onPartitionReassignment 。扩容时，需要停止Producer和Consumer。

4.高可用

4.1 high water mark

1. high water mark通常是一个partition所有replica的endOffset的最小值，也是同步提交模式情况下集群commit的位置
2. 读的时候客户端最多只能读到highWatermark的位置
3. 一个follower挂掉重启的时候首先扔掉它自己highWatermark之后的数据，然后开始追赶leader
4. leader挂掉的会重新选，新leader把自己的endOffset当做新的highWatermark，然后让其它的replica开始追赶

4.2 in sync replica

1. Partition会启动一个超时线程，调用Partition.maybeShrinkIsr，检查所有isr的end offset和最后更新时间，差距过大的就踢掉
2. 处理follower的fetch request的时候可能会触发Partition.updateLeaderHWAndMaybeExpandIsr，重新检查这个replica的各种条件，可能的话就加回到isr

4.3 partition leader election

1. PartitionLeaderSelector.OfflinePartitionLeaderSelector是用得最多的leader selector，选leader的逻辑是从controller context里面拿出live isr和live replica，优先选择live isr的第一个，如果没有就选择live replica的第一个，否则就抛异常
2. 更新zk path /brokers/topics/huying_test1/partitions/0/state
3. 给这个partition的每个replica broker发一个请求LeaderAndIsrRequest，其中leader和follower的指令稍有区别。然后给所有活着的broker发一个请求UpdateMetadataRequest。这里的请求都是异步带callback(多数情况是null)的
4. 发送请求如果失败会重试，终止重试的流程是zk那边发起，导致当前发送线程被关闭
5. 接收到请求的broker开始ReplicaManager.makeLeaders, makeFollowers相关的流程
6. 处理UpdateMetadataRequest请求比较简单，更新一下cache数据就ok了
7. 触发点，KafkaController.onBrokerStartup, KafkaController.onBrokerFailure分别对应broker启动的时候和broker挂掉的时候，KafkaController.onPreferredReplicaElection，使用了工具:kafka-preferred-replica-election.sh

4.4 controller leader election

1. controller是kafka全局的leader，controller负责监听zookeeper然后分析状态变更发送命令到其它的broker
2. broker启动的时候开始监听/controller节点，这里注意一个zk的bug(session失效可能过了一段时间临时节点才会删除，如果碰到node exist exception就返回可能会都选不上) LeaderChangeListener可能会触发KafkaController.onControllerFailover或者KafkaController.onControllerResignation
3. onControllerFailover首先会读取zk上的epoch，然后+1乐观锁方式更新zk，epoch用来标识正确的leader，当新leader产生旧leader没挂掉的时候可以作废掉旧leader的命令，broker里面关注epoch的manager保存一份epoch，接到比自己大的epoch就设定成新的
4. 监听几个zk path，/admin/reassign_partitions，/admin/preferred_replica_election，/brokers/topics，/admin/delete_topics，/brokers/ids，/brokers/topics/topicXXX
5. 初始化controllerContext相关的内存结构和一些manager，并给其它的broker发一个metadata更新的命令
6. 如果配了自动平衡partition leader，就启动一个检查并自动平衡partition leader的scheduler，调用checkAndTriggerPartitionRebalance，不平衡率高的时候触发onPreferredReplicaElection
   
   7.onControllerResignation执行相反的过程，取消注册之前的几个zk listener并且关闭几个manager

5.broker启动和关闭

1. broker启动的时候注册SessionExpireListener，这里调用的是zkClient.subscribeStateChanges(sessionExpireListener)而不是监听zk临时节点，感觉碰到机器假死会少了删临时节点的手段。然后注册临时节点/brokers/ids/xxx，这个临时节点会被controller的BrokerChangeListener监听
2. KafkaController.onBrokerStartup 首先给新启动的broker发送metadata
3. 给新broker上的所有replica触发OnlineReplica的状态变更，会触发broker上面的replicaManager.becomeLeaderOrFollower，具体的逻辑和前面创建topic里面描述的相同
4. 触发partitionStateMachine的状态变更，可能会导致leader重新选举，同时也会触发broker上面的replicaManager.becomeLeaderOrFollower
5. 如果在新的broker上有partition reassignment，就调用onPartitionReassignment
6. broker关闭的逻辑类似，也是触发partitionStateMachine和replicaStateMachine的状态变化，稍有不同的是那些leader在这台broker上的partition要先触发一个Offline再触发一个Online

6.高性能

1. 磁盘顺序写速度很快，pagecache的存在加速读写
2. 攒消息成message set，网络上传大包，更大块的磁盘操作，内存连续性更好
3. 协议固定，消息字节在broker，consumer，producer之间传输不需要修改
4. 字节从pagecache到socket在linux可以通过sendfile优化