我已经使用 Kafka 近两年了,我发现有两个配置很重要,但是不太容易理解。这两个配置分别是acks和min.insync.replicas。
本文将通过一些插图来帮助理解这2个配置,以便更好的使用Kafka为我们服务。
复制
我假设你已经熟悉 Kafka了 ,但为了更好地理解这些配置,还是有必要回顾一下Kafka的基础知识。
在Kafka中,每个主题的分区由一个 leader 副本 和若干个 follower 副本 组成,副本个数(leader副本和follower副本之和)可以通过replication.factor
进行配置,其默认值是3,这也是一般场景下推荐的值,这种设置能够提供一定的容错能力和数据冗余,确保数据的可靠性。见下图。
生产者客户端只会向leader副本写入数据,而follower副本只负责异步复制数据,不会对外提供服务,也就是说对于客户端而言,Kafka的Follower副本并不起直接作用。
由于分布式系统的复杂性,我们需要一种方法来判断这些follower是否跟上leader的步伐——它们是否将生产者写入到leader中的最新数据同步过来?
同步副本(In-sync Replicas)
在数据同步过程中,follower副本 相对于 leader副本 而言可能会有一定程度上的滞后。根据这个特性,Kafka 中的副本被分为两个集合:ISR(In-Sync Replicas) 和 OSR(Out-of-Sync Replicas)。
-
ISR集合:所有与 leader 副本保持一定程度同步的副本(包括 leader 副本在内)组成的集合。当Leader副本出现故障后,只有这个集合中的 副本才能被选举为leader((不过可以修改参数配置来改变这个行为)。)。
-
OSR集合:与 leader 副本同步滞后过多的副本组成的集合。
leader副本负责维护和跟踪 ISR 集合中所有 follower 副本的同步状态,当某个 follower 副本的滞后程度过高时,leader副本 会将它从 ISR 集合中剔除。当然,如果 OSR 集合中有 follower 同步进度追上了 leader,那么 leader 也会把它从 OSR 集合中转移至 ISR 集合。
acks配置
了解了 Kafka 的副本机制后,我们可以探讨 acks 配置了。
acks
是生产者客户端的一个配置选项,它表示生产者发送的消息要有多少个副本节点接收到,生产者才认为消息发送成功,其取值可以为0、1、-1(也可以表示为 all)。
acks=0
当 acks 设置为 0 时,生产者在发送消息后不需要等待来自broker的确认信息,生产者在消息发送出去后就认为写入成功。这种设置具有最高的效率,但最容易导致消息丢失,因为生产者不等待任何确认。
acks=1
当 acks 设置为 1 时,只要leader副本已经收到消息并将其写入本地日志中,就会返回ack给生产者,这种方式的安全性较高,但仍然存在一定的消息丢失风险:考虑到这样一个场景,生产者发送的消息确实成功写入到了leader副本,leader副本就会返回成功响应给生产者,但是这条消息还没来得及同步到follower副本中,此时leader副本崩溃,那么这条消息还是会丢失,因为新选举的leader副本中并没有这条对应的消息。
相对其它两种设置,ack=1这种配置性能和安全是最均衡的。
acks=all
当 acks 设置为 -1 或者all时,leader等待所有同步副本都收到该消息后才会返回ack给生产者。保证了只要有⼀个同步副本存在,消息就不会丢失,这种方式最安全,但性能最差。
min.insync.replicas
如果系统对数据安全性要求高,不允许丢数据,那么需要将acks配置为all。但是仅配置acks=all还是会存在问题。
如果一个分区有3个副本,正常情况ISR里面就是3个副本,但由于网络等问题ISR集合里面的副本数量可能会变化,当ISR集合的副本减少到只有 1 个时,也就是说leader是唯一同步副本,acks=all其实就退化成acks=1了(只需要leader副本保存好消息就返回ack),前面我们已经介绍过,acks = 1是会存在消息丢失的可能。
为了防止这种情况发生,可以使用 min.insync.replicas 配置。
min.insync.replicas是broker上的配置,它指定了当acks=all时,ISR 中必须存在的最少同步副本数量。如果 ISR 中的同步副本数量小于这个值,写入操作将会失败,对于不能忍受消息丢失的系统来说,写入失败总比写进去然后丢了强。
例如,在下图中,有2个同步副本(Broker 3 不是同步副本),并且在生产者上设置了acks=all, broker上设置了min.insync.replicas=2,那么意味着当两个同步副本都收到消息后,leader才会返回ack给生产者。
如果同步副本数量低于这个值,生产者将收到异常,下图中, Brokers 2 and 3都不是同步副本,同步副本只有leader1个,但是min.insync.replicas=2,也就是说同步副本数小于这个min.insync.replicas设置的值,因此,任何消息的写入都将会失败。
需要注意的是,对于下图这种情况,使用acks=0或acks=1配置的生产者会成功将消息6写入分区。
误区
一个常见的误解是:认为min.insync.replicas表示有多少副本需要收到消息才能让leader响应ack给生产者。
事实并非如此,实际上,min.insync.replicas表示在处理请求时需要存在的最少同步副本数量。
以下图为例。即使配置了min.insync.replicas=2,leader也不会在仅有2个副本确认的情况下响应ack给生产者,而是等待所有3个副本确认才会响应ack给生产者。
这就是全部内容!配合插图是不是很容易理解?