Kafka的复制机制。。。。

复制功能是kafka架构的核心，kafka自己描述的“一个分布式的、可分区的、可复制的日志提交服务”。复制保证了在集群的个别节点失效时仍然能保证kafka的可用性和持久。

kafka使用topic来组织数据的，每个topic包含若干个partition,每个partition的有多个副本，这些副本都是保持在broker上面的。

副本类型：

   leader副本：每个分区都有一个leader, 为了保证数据的一致性，所有的生产者请求和消费者请求都是经过leader来处理的。

   follower副本：follower副本不处理来自客户端的请求，它们唯一的事情就是从leader哪里复制消息，保持与leader一直的状态。如果leader挂了，其中一个follower会被提升为新的leader的。

leader的另外一个任务是搞清楚那个follower的状态跟自己是一样的。为了follower与leader的状态一致，在有消息到达时尝试从leader那里进行复制，可能会由于一些原因造成同步失败。例如：网络拥堵导致复制变慢，broker发生崩溃导致复制失败，直到broker重启之后再继续。

为了与leader保持同步的，follower向leader发送获取数据的请求，这种请求是和消费者获取数据的请求是一样的，leader把响应的数据发送给follower，在消费者发送的请求里面是包含了消息的偏移量的，而且这些偏移量总是有序的。

在follower在发送获取同步数据的请求的过程：

一个follower先发送request1，接着request2, request3,在follower接受到这三个响应之前，是不会再接着发送第四个请求了。如果说leader已经接受到了follwer的第四个请求的话，则前面三个请求的响应数据follower已经接受到了。leader都会定期去查看每一个follower的最新的偏移量的，就会知道每个follower的最新的进度。此时，如果follower在10s内没有发起获取数据的请求，或者是芮虽然在请求消息，但是10s内没有请求最新的数据，那么就会被认为是不同步的。如果一个follower无法与leader保持一致的话，那么在leader失效的情况下，它是不会成为新的leader的候选者的。-- 因为它没有包括最新的消息的。

相反，在持续获得最新的数据的follower才会被称为同步的副本。在leader失效的时候，才有可能被选为leader的。

另外，每一个分区都有一个首选leader的，所谓的首选leader，就是在创建分区的时候选定的leader就是分区的首选leader。在创建分区时，需要在broker之间均衡首选。因此，在首选leader成为真正的leader时，broker之间的负载均衡得到最终的平衡，默认情况下，kafka的  auto.leader.rebalance.enable 设置为true, 它会去检查首选leader是不是当前的leader，如果不是，并且该副本是同步的，那么就会触发首选leader的选举行为，让首选leader成为当前的leader。

分区leader是同步副本，那么follower的副本需要满足一下的条件才能算是同步副本：

条件一：与Zookeeper之间有一个活跃的会话，也就是说，它必须在过去的6s（可配置的）时间之内向zookeeper发送过心跳。

条件二：在过去10s（可配置）内从leader那边获取过消息。

条件三：在过去10s（可配置）时间内从leader那边获取过最新的消息的。而且时间上几乎是同步的（延时为0）。