图解Kafka | 彻底弄明白 Kafka 两个最重要的配置

我已经使用 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给生产者。

这就是全部内容！配合插图是不是很容易理解？