上一篇有很大一部分也提到了正本同步机制，但有些细节点没提到，这里再转载一篇文章来聊聊正本同步机制。

正本同步机制

咱们晓得,kafka每个topic的partition会有N个正本，kafka通过多正本机制实现故障主动转移，当kafka集群中一个broker生效状况下，会在N个正本中从新选出一个broker作为leader提供服务，从而做到高可用。N个正本中，其中一个为leader，其余的都为follower，leader解决partition的所有读写申请，follower会定期地复制leader上的数据。

Kafka提供了数据复制算法，如果leader产生故障或挂掉，Kafka确保从同步正本列表中选举一个正本为leader，新leader被选举并被承受客户端的音讯写入。leader负责保护ISR（In-Sync Replicas的缩写，示意正本同步队列）中所有音讯。当producer发送一条音讯到broker后，leader写入音讯，并复制到所有follower。音讯提交之后才被胜利复制到所有的同步正本。音讯复制提早受最慢的follower限度，kafka会检测慢正本，如果follower“落后”太多或者失败，leader将会把他从ISR中删除。

正本同步队列ISR

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

  1. 正本节点必须能与zookeeper放弃会话（心跳机制）
  2. 副本能复制leader上的所有写操作，并且不能落后太多（卡主或滞后的正本管制由replica.lag.time.max.ms配置）

默认状况下，Kafka topic的replica数量为1，即每个partition都有一个惟一的leader，为了确保音讯的可靠性，通常利用中将其值（由broker的参数offsets.topic.replication.factor指定）大小设定为1。所有的正本（replicas）统称为AR (Assigned Replicas）。ISR是AR的一个子集，由leader保护ISR列表，follower从Leader同步数据有一些提早，任意一个超过阈值都会把follower踢出ISR，存入OSR（Outof-Sync Replicas）列表，新退出的follower也会先寄存到OSR中。AR = ISR + OSR

HW（HighWatermark）俗称高水位，取一个partition对应的ISR中最小的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(log end offset)的流转过程：

由此可见，Kafka的复制机制既不是齐全的同步复制，也不是单纯的异步复制。事实上，同步机制要求所有能工作的follower都复制完，这条音讯才会被commit，这种复制形式极大的影响了吞吐率。而异步复制形式下，follower异步的从leader复制数据，数据只有被Leader写入log就被工作曾经commit，这种状况下如果follower没有全复制完，落后与Leader，忽然leader宕机，则会丢数据。而Kafka这种应用ISR的形式则很好的平衡了确保数据不失落以及吞吐率。

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

  1. Controller保护：Kafka集群中的其中一个Broker会被选举为Controller，次要负责Partition治理和正本状态治理，也会执行相似于重调配partition之类的治理工作。在合乎某些特定条件下，Controller下的LeaderSelector会选举新的leader, ISR和新的leader_epoch及controller_epoch写入Zookeeper的相干节点中。同时发动LeaderAndIsrRequest告诉所有的replicas。
  2. leader来保护：leader有独自的线程定期检查ISR中follower是否脱离ISR，如果发现ISR变动，则会将新的ISR的信息返回到Zookeeper的相干节点中。

正本不同的异常情况：

  1. 慢正本：在肯定周期时间内，follower不能追赶上leader。最常见的起因之一是IO瓶颈导致follower追加复制音讯速度鳗鱼从leader拉取速度
  2. 正本卡住：在肯定周期时间内，follower进行从leader拉取申请。follower replica卡住了是因为GC暂停或follower生效或死亡。
  3. 新启动正本：当用户给topic减少正本因子时，新的follower不再同步正本列表中，直到他们齐全追赶上leader日志。