kafka知识体系-副本同步机制

╰+哭是因爲堅強的太久メ 2023-03-14 13:17 2阅读 0赞

![format_png][]

点击上方「蓝字」关注我们

![format_png 1][]

![format_png 2][]

本系列主要讲解kafka基本设计和原理分析，分如下内容：

1.  基本概念
2.  消息模型
3.  kafka副本同步机制
4.  kafka文件存储机制
5.  kafka数据可靠性和一致性保证
6.  kafka leader选举
7.  kafka消息传递语义
8.  Kafka集群partitions/replicas默认分配解析

##     ##

##  ##

kafka副本同步机制

##     ##

Kafka中主题的每个Partition有一个预写式日志文件，每个Partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到Partition中，Partition中的每个消息都有一个连续的序列号叫做offset， 确定它在分区日志中唯一的位置。  
![format_png 3][]

Kafka每个topic的partition有N个副本，其中N是topic的复制因子。Kafka通过多副本机制实现故障自动转移，当Kafka集群中一个Broker失效情况下仍然保证服务可用。

在Kafka中发生复制时确保partition的预写式日志有序地写到其他节点上。N个replicas中。其中一个replica为leader，其他都为follower，leader处理partition的所有读写请求，与此同时，follower会被动定期地去复制leader上的数据。

如下图所示，Kafka集群中有4个broker, 某topic有3个partition,且复制因子即副本个数也为3：  
![format_png 4][]

Kafka提供了数据复制算法保证，如果leader发生故障或挂掉，一个新leader被选举并被接受客户端的消息成功写入。

Kafka确保从同步副本列表中选举一个副本为leader，或者说follower追赶leader数据。

leader负责维护和跟踪ISR(In-Sync Replicas的缩写，表示副本同步队列，具体可参考下节)中所有follower滞后的状态。

当producer发送一条消息到broker后，leader写入消息并复制到所有follower。消息提交之后才被成功复制到所有的同步副本。

消息复制延迟受最慢的follower限制，重要的是快速检测慢副本，如果follower“落后”太多或者失效，leader将会把它从ISR中删除。

##  ##

副本同步队列(ISR)

所谓同步，必须满足如下两个条件：

*  副本节点必须能与zookeeper保持会话（心跳机制）
 *  副本能复制leader上的所有写操作，并且不能落后太多。(卡住或滞后的副本控制是由 replica.lag.time.max.ms 配置)

默认情况下Kafka对应的topic的replica数量为1，即每个partition都有一个唯一的leader，为了确保消息的可靠性，通常应用中将其值(由broker的参数offsets.topic.replication.factor指定)大小设置为大于1，比如3。

所有的副本（replicas）统称为Assigned Replicas，即AR。

ISR是AR中的一个子集，由leader维护ISR列表，follower从leader同步数据有一些延迟。任意一个超过阈值都会把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

上一节中的最小的LEO作为HW，consumer最多只能消费到HW所在的位置。

另外每个replica都有HW,leader和follower各自负责更新自己的HW的状态。对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。

这样就保证了如果leader所在的broker失效，该消息仍然可以从新选举的leader中获取。对于来自内部broKer的读取请求，没有HW的限制。

下图详细的说明了当producer生产消息至broker后，ISR以及HW和LEO的流转过程：

![format_png 5][]

由此可见，Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的follower都复制完，这条消息才会被commit，这种复制方式极大的影响了吞吐率。

而异步复制方式下，follower异步的从leader复制数据，数据只要被leader写入log就被认为已经commit，这种情况下如果follower都还没有复制完，落后于leader时，突然leader宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。

Kafka的ISR的管理最终都会反馈到Zookeeper节点上。具体位置为：/brokers/topics/\[topic\]/partitions/\[partition\]/state。目前有两个地方会对这个Zookeeper的节点进行维护：

*  Controller来维护：Kafka集群中的其中一个Broker会被选举为Controller，主要负责Partition管理和副本状态管理，也会执行类似于重分配partition之类的管理任务。在符合某些特定条件下，Controller下的LeaderSelector会选举新的leader，ISR和新的leader\_epoch及controller\_epoch写入Zookeeper的相关节点中。同时发起LeaderAndIsrRequest通知所有的replicas。
 *  leader来维护：leader有单独的线程定期检测ISR中follower是否脱离ISR, 如果发现ISR变化，则会将新的ISR的信息返回到Zookeeper的相关节点中。

##  ##

副本不同步的异常情况

*  慢副本：在一定周期时间内follower不能追赶上leader。最常见的原因之一是I / O瓶颈导致follower追加复制消息速度慢于从leader拉取速度。
 *  卡住副本：在一定周期时间内follower停止从leader拉取请求。follower replica卡住了是由于GC暂停或follower失效或死亡。
 *  新启动副本：当用户给主题增加副本因子时，新的follower不在同步副本列表中，直到他们完全赶上了leader日志。

![format_png 6][]

往期推荐

![format_png 7][]

*  [Kafka消息丢失与消费精确一次性][Kafka]  
    
 *  [Kafka性能调优分析-线上环境篇][Kafka_-]  
    
 *  [Kafka数据管道][Kafka 1]  
    
 *  [kafka 高吞吐量性能揭秘][kafka]

![format_png 8][]

点“在看”你懂得

![format_png 9][]

[format_png]: /images/20230312/2107beb121034d1896eacb0c92e7a9ca.png
[format_png 1]: /images/20230312/251559ced02c43d3a489a7af3442c3b2.png
[format_png 2]: /images/20230312/a57c0494bb2943869c9406d319111b2d.png
[format_png 3]: /images/20230312/6cd1177d1cfb454fa6fefd9ad295f035.png
[format_png 4]: /images/20230312/0835914fe7c64c37bfc8248b9a7d920b.png
[format_png 5]: /images/20230312/7bb6aa25ce44481c84af2d339cc8d496.png
[format_png 6]: /images/20230312/730794378fce4d10854d2671490645d5.png
[format_png 7]: /images/20230312/260d0175de81401a8646cae87a0fa153.png
[Kafka]: https://blog.csdn.net/u012811805/article/details/106168982
[Kafka_-]: https://blog.csdn.net/u012811805/article/details/106152956
[Kafka 1]: https://blog.csdn.net/u012811805/article/details/106132614
[kafka]: https://blog.csdn.net/u012811805/article/details/106110885
[format_png 8]: /images/20230312/60203b98c5e246f093d14c3c711bc231.png
[format_png 9]: /images/20230312/6a162c9520584d0382dac67ced4c3966.png