Kafka - min.insync.replicas 解读
Kafka - min.insync.replicas interpretation
我正在查看多个地方的文档，这增加了混乱..
关于 属性 min.insync.replicas
When a producer sets acks to "all" (or "-1"), this configuration
specifies the minimum number of replicas that must acknowledge a write
for the write to be considered successful. If this minimum cannot be
met, then the producer will raise an exception (either
NotEnoughReplicas or NotEnoughReplicasAfterAppend). When used
together, min.insync.replicas and acks allow you to enforce greater
durability guarantees. A typical scenario would be to create a topic
with a replication factor of 3, set min.insync.replicas to 2, and
produce with acks of "all". This will ensure that the producer raises
an exception if a majority of replicas do not receive a write.
我的问题，
- 这个 属性 只有在作为 "Sending the record"（生产者）的一部分与 "acks" 一起使用时才有意义吗？或者它作为消费者流程的一部分有任何影响吗？嗯？
- 如果 acks=all 和 min.insync.replicas = 1（默认值：1）怎么办 --> 是否与 acks = 1 相同？ （考虑复制因子 3 ?
更新#1
我遇到这个 phrase
"When a producer specifies ack (-1 / all config) it will still wait for acks from all in sync replicas at that moment (independent of the setting for min in-sync replicas). So if you publish when 4 replicas are in sync then you will not get an ack unless all 4 replicas commit the message (even if min in-sync replicas is configured as 2)."
这个短语与今天有什么关系？这个 属性 "min in-sync replicas" 仍然独立吗？
这里有两个设置会影响生产者：
acks - 这是生产者级别的设置min.insync.replicas - 这是主题级别的设置
acks 属性 决定了你想如何处理写入kafka：
acks=0 - 我不关心是否收到回执
acks=1 - 当 leader 分区收到内存中的批次时发送确认
all/-1 - 在发送确认之前等待 all 个副本接收批次
记住，分区中的收据是在内存中，Kafka 默认情况下不等待 fsync 到磁盘，所以 acks=1 不是持久写入！
min.insync.replicas用于题目出现问题时，可能其中一个分区不同步，或者离线。在这种情况下，集群将在满足 min.insync.replicas 时发送确认。所以 3 个副本， min.insync.replicas=2 仍然可以写：
acks 属性 对消费者没有影响，只是在 acks 和 min.insync.replicas 满足之前不会写入数据。
What if acks=all and min.insync.replicas = 1(default value :1 ) --> Is it same as acks = 1 ? ( considering replication-factor 3 ?
只有题目有问题。如果您有 3 个副本，并且 min.insync.replicas=1 和 两个 分区已关闭，这与 acks=1 相同。如果主题是健康的，生产者将在发送 ack 之前等待 all 个副本。
我正在查看多个地方的文档，这增加了混乱..
关于 属性 min.insync.replicas
When a producer sets acks to "all" (or "-1"), this configuration specifies the minimum number of replicas that must acknowledge a write for the write to be considered successful. If this minimum cannot be met, then the producer will raise an exception (either NotEnoughReplicas or NotEnoughReplicasAfterAppend). When used together, min.insync.replicas and acks allow you to enforce greater durability guarantees. A typical scenario would be to create a topic with a replication factor of 3, set min.insync.replicas to 2, and produce with acks of "all". This will ensure that the producer raises an exception if a majority of replicas do not receive a write.
我的问题，
- 这个 属性 只有在作为 "Sending the record"（生产者）的一部分与 "acks" 一起使用时才有意义吗？或者它作为消费者流程的一部分有任何影响吗？嗯？
- 如果 acks=all 和 min.insync.replicas = 1（默认值：1）怎么办 --> 是否与 acks = 1 相同？ （考虑复制因子 3 ?
更新#1 我遇到这个 phrase
"When a producer specifies ack (-1 / all config) it will still wait for acks from all in sync replicas at that moment (independent of the setting for min in-sync replicas). So if you publish when 4 replicas are in sync then you will not get an ack unless all 4 replicas commit the message (even if min in-sync replicas is configured as 2)."
这个短语与今天有什么关系？这个 属性 "min in-sync replicas" 仍然独立吗？
这里有两个设置会影响生产者：
acks- 这是生产者级别的设置min.insync.replicas- 这是主题级别的设置
acks 属性 决定了你想如何处理写入kafka：
acks=0 - 我不关心是否收到回执
acks=1 - 当 leader 分区收到内存中的批次时发送确认
all/-1 - 在发送确认之前等待 all 个副本接收批次
记住，分区中的收据是在内存中，Kafka 默认情况下不等待 fsync 到磁盘，所以 acks=1 不是持久写入！
min.insync.replicas用于题目出现问题时，可能其中一个分区不同步，或者离线。在这种情况下，集群将在满足 min.insync.replicas 时发送确认。所以 3 个副本， min.insync.replicas=2 仍然可以写：
acks 属性 对消费者没有影响，只是在 acks 和 min.insync.replicas 满足之前不会写入数据。
What if acks=all and min.insync.replicas = 1(default value :1 ) --> Is it same as acks = 1 ? ( considering replication-factor 3 ?
只有题目有问题。如果您有 3 个副本，并且 min.insync.replicas=1 和 两个 分区已关闭，这与 acks=1 相同。如果主题是健康的，生产者将在发送 ack 之前等待 all 个副本。