acks和min.insync.replicas配置详解,通俗易懂 一看就会

Posted 总要冲动一次

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了acks和min.insync.replicas配置详解,通俗易懂 一看就会相关的知识,希望对你有一定的参考价值。

acks

描述:producer 发送数据服务端的响应级别

acks = all/-1 : 表示kafka isr列表中所有的副本同步数据成功,才返回消息给客户端
acks = 0 :表示客户端只管发送数据,不管服务端接收数据的任何情况
acks = 1 :表示客户端发送数据后,需要在服务端 leader 副本写入数据成功后,返回响应

min.insync.replicas

描述:Kafka ISR 列表中最小同步副本数

默认 min.insync.replicas = 1

当 acks = all/-1 时,建议 min.insync.replicas 的值大于1 且小于 replication.factor 副本数

建议 min.insync.replicas = 2 #当 acks = -1/all 时

总结一下

设置acks=all,且副本数为3
极端情况1:
默认min.insync.replicas=1,极端情况下如果ISR中只有leader一个副本时满足min.insync.replicas=1这个条件,此时producer发送的数据只要leader同步成功就会返回响应,如果此时leader所在的broker crash了,就必定会丢失数据!这种情况不就和acks=1一样了!所以我们需要适当的加大min.insync.replicas的值。

极端情况2:
min.insync.replicas=3(等于副本数),这种情况下要一直保证ISR中有所有的副本,且producer发送数据要保证所有副本写入成功才能接收到响应!一旦有任何一个broker crash了,ISR里面最大就是2了,不满足min.insync.replicas=3,就不可能发送数据成功了!

根据这两个极端的情况可以看出min.insync.replicas的取值,是kafka系统可用性和数据可靠性的平衡!

  1. 减小 min.insync.replicas 的值,一定程度上增大了系统的可用性,允许kafka出现更多的副本broker crash并且服务正常运行;但是降低了数据可靠性,可能会丢数据(极端情况1)。
  2. 增大 min.insync.replicas 的值,一定程度上增大了数据的可靠性,允许一些broker crash掉,且不会丢失数据(只要再次选举的leader是从ISR中选举的就行);但是降低了系统的可用性,会允许更少的broker crash(极端情况2)。

官网中关于min.insync.replicas参数的描述如下:

当生产者将确认设置为“all”(或“-1”)时,min.insync.replicas 指定必须确认写入的最小副本数才能被视为成功。如果无法满足此最小值,则生产者将引发异常(NotEnoughReplicas 或 NotEnoughReplicasAfterAppend)。
当一起使用时,min.insync.replicas 和 acks 允许您强制执行更大的持久性保证。一个典型的场景是创建一个复制因子为 3 的主题,将 min.insync.replicas 设置为 2,并使用“all”的 acks 生成。如果大多数副本没有收到写入,这将确保生产者引发异常。

参考:https://www.szzdzhp.com/kafka/qa/acksAndMir.html

先这样,后面有需要在增改!

以上是关于acks和min.insync.replicas配置详解,通俗易懂 一看就会的主要内容,如果未能解决你的问题,请参考以下文章

关于kafka数据丢失场景的一次激烈讨论....

关于kafka数据丢失场景的一次激烈讨论.... |文末送书

kafka线上问题优化:消息丢失重复消费消息积压延时队列顺序消费

kafka线上问题优化:消息丢失重复消费消息积压延时队列顺序消费

Confent Kafka Python生产者未使用ACKS =所有配置进行生产

Spring Kafka - 事务回滚后重试时,通过侦听器容器事务发布消息和提交记录偏移失败