kafka副本同步机制

　　kafka副本同步机制

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

　　

　　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：

　　

　　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。

　　上一节中的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的流转过程：

　　

　　因而可知，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日志。

​