Kafka参数图鉴——unclean.leader.election.enable

Kafka参数图鉴——unclean.leader.election.enable

如何提高Kafka可靠性是一个可以长篇大论的主题。很多初学者会简单的认为将客户端参数acks设置为-1即可保证Kafka的可靠性,显然这是很片面的观点。就可靠性本身而言,它并不是一个可以用“是”或者“否”来衡量的一个指标,而一般是用几个9来衡量。就参数方面而言,与Kafka可靠性相关的参数不止acks这一个,比如retries、replication.factor、min.insync.replicas、unclean.leader.election.enable等等,某些参数还要级联配置。

本文主要阐述的是Kafka可靠性相关参数中的一个,即unclean.leader.election.enable。随着Kafka版本的变更,有的参数消失,也有的参数被加入进来,而传承下来的参数一般都不太会修改既定的默认值,而unclean.leader.election.enable参数却是其中的一个反例。从Kafka 0.11.0.0版本开始unclean.leader.election.enable参数的默认值由原来的true改为false,这个参数背后到底意味着什么,Kafka的设计者处于什么原因要修改这个默认值?

参考上图,某种状态下,follower2副本落后leader副本很多,并且也不在leader副本和follower1副本所在的ISR(In-Sync Replicas)集合之中。follower2副本正在努力的追赶leader副本以求迅速同步,并且能够加入到ISR中。但是很不幸的是,此时ISR中的所有副本都突然下线,情形如下图所示:

此时follower2副本还在,就会进行新的选举,不过在选举之前首先要判断unclean.leader.election.enable参数的值。如果unclean.leader.election.enable参数的值为false,那么就意味着非ISR中的副本不能够参与选举,此时无法进行新的选举,此时整个分区处于不可用状态。如果unclean.leader.election.enable参数的值为true,那么可以从非ISR集合中选举follower副本称为新的leader。

我们进一步考虑unclean.leader.election.enable参数为true的情况,在上面的这种情形中follower2副本就顺其自然的称为了新的leader。随着时间的推进,新的leader副本从客户端收到了新的消息,如上图所示。

此时,原来的leader副本恢复,成为了新的follower副本,准备向新的leader副本同步消息,但是它发现自身的LEO比leader副本的LEO还要大。Kafka中有一个准则,follower副本的LEO是不能够大于leader副本的,所以新的follower副本就需要截断日志至leader副本的LEO处。

如上图所示,新的follower副本需要删除消息4和消息5,之后才能与新的leader副本进行同步。之后新的follower副本和新的leader副本组成了新的ISR集合,参考下图。

原本客户端已经成功的写入了消息4和消息5,而在发生日志截断之后就意味着这2条消息就丢失了,并且新的follower副本和新的leader副本之间的消息也不一致。也就是说如果unclean.leader.election.enable参数设置为true,就有可能发生数据丢失和数据不一致的情况,Kafka的可靠性就会降低;而如果unclean.leader.election.enable参数设置为false,Kafka的可用性就会降低。具体怎么选择需要读者更具实际的业务逻辑进行权衡,可靠性优先还是可用性优先。从Kafka 0.11.0.0版本开始将此参数从true设置为false,可以看出Kafka的设计者偏向于可靠性,如果能够容忍uncleanLeaderElection场景带来的消息丢失和不一致,可以将此参数设置为之前的老值——true。


欢迎支持笔者的作品《深入理解Kafka: 核心设计与实践原理》和《RabbitMQ实战指南》,同时欢迎关注笔者的微信公众号:朱小厮的博客(ID: hiddenkafka)。
本文作者: 朱小厮

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×