图解Kafka | 彻底弄明白 Kafka 两个最重要的配置
我已经利用 Kafka 近两年了，我发现有两个配置很重要，但是不太容易理解。这两个配置分别是acks和min.insync.replicas。本文将通过一些插图来资助理解这2个配置，以便更好的利用Kafka为我们服务。
复制
我假设你已经熟悉 Kafka了 ，但为了更好地理解这些配置，照旧有必要回首一下Kafka的基础知识。
在Kafka中，每个主题的分区由一个 leader 副本 和若干个 follower 副本 构成，副本个数（leader副本和follower副本之和）可以通过replication.factor举行配置，其默认值是3，这也是一般场景下推荐的值，这种设置能够提供肯定的容错本领和数据冗余，确保数据的可靠性。见下图。
https://img-blog.csdnimg.cn/img_convert/271c0d351c08337409f453db0682458a.png
生产者客户端只会向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 集合。
https://img-blog.csdnimg.cn/img_convert/d1324770c8e5d8ebd2c1b6246d131205.png
acks配置
相识了 Kafka 的副本机制后，我们可以探讨 acks 配置了。
acks是生产者客户端的一个配置选项，它表示生产者发送的消息要有多少个副本节点接收到，生产者才认为消息发送乐成,其取值可以为0、1、-1(也可以表示为 all)。
acks=0
当 acks 设置为 0 时，生产者在发送消息后不需要等待来自broker的确认信息，生产者在消息发送出去后就认为写入乐成。这种设置具有最高的服从，但最容易导致消息丢失，因为生产者不等待任何确认。
https://img-blog.csdnimg.cn/img_convert/5c273efef5b67c89b43d4d33d35df4a8.png
acks=1
当 acks 设置为 1 时，只要leader副本已经收到消息并将其写入当地日志中，就会返回ack给生产者，这种方式的安全性较高，但仍旧存在肯定的消息丢失风险：考虑到这样一个场景，生产者发送的消息确实乐成写入到了leader副本，leader副本就会返回乐成相应给生产者，但是这条消息还没来得及同步到follower副本中，此时leader副本崩溃，那么这条消息照旧会丢失，因为新选举的leader副本中并没有这条对应的消息。
相对别的两种设置，ack=1这种配置性能和安满是最平衡的。
https://img-blog.csdnimg.cn/img_convert/15c5285c6ec45d21d63c9c1b874fe617.png
acks=all
当 acks 设置为 -1 大概all时，leader等待全部同步副本都收到该消息后才会返回ack给生产者。保证了只要有⼀个同步副本存在，消息就不会丢失，这种方式最安全，但性能最差。
https://img-blog.csdnimg.cn/img_convert/ebb27eacc2bc6100c54ab7ae72a7b5f1.png
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给生产者。
https://img-blog.csdnimg.cn/img_convert/e12515a4da85f1cdfd0038cc4e1ea880.png
如果同步副本数量低于这个值，生产者将收到异常，下图中， Brokers 2 and 3都不是同步副本，同步副本只有leader1个，但是min.insync.replicas=2，也就是说同步副本数小于这个min.insync.replicas设置的值，因此，任何消息的写入都将会失败。
需要留意的是，对于下图这种环境，利用acks=0或acks=1配置的生产者会乐成将消息6写入分区。
https://img-blog.csdnimg.cn/img_convert/cd6fa450c8d30e254d3eceaeb9b87b5c.png
误区
一个常见的误解是：认为min.insync.replicas表示有多少副本需要收到消息才气让leader相应ack给生产者。
事实并非云云，实际上，min.insync.replicas表示在处理哀求时需要存在的最少同步副本数量。
以下图为例。纵然配置了min.insync.replicas=2，leader也不会在仅有2个副本确认的环境下相应ack给生产者，而是等待全部3个副本确认才会相应ack给生产者。
https://img-blog.csdnimg.cn/img_convert/d239ce997e102fb3ad8ce360a4bffff0.png
这就是全部内容！共同插图是不是很容易理解？
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]