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)。

猜你喜欢

转载自blog.csdn.net/tryll/article/details/86627696