Kafka集群各Broker配置不同min.insync.replicas时，最终生效值是哪个？

首先得澄清一个关键误区：min.insync.replicas本质是topic级别的配置，而broker的server.properties里的配置（准确来说是default.min.insync.replicas，你可能笔误写成了min.insync.replicas）只是用来给新创建的topic设置默认值的，并不是全局强制生效的参数。结合你描述的场景（Broker3是控制器，各broker的默认配置分别为2、3、4），分两种情况来看：

1. 针对已存在的Topic #

如果这些topic在创建时没有显式指定min.insync.replicas，那么它们的这个参数值是创建时负责处理请求的控制器所在broker的默认配置值，之后哪怕控制器切换、各broker的默认配置修改，都不会自动改变已存在topic的这个参数——除非你手动用kafka-configs.sh命令去修改topic的配置。

举个例子：如果某个topic是之前Broker1当控制器时创建的，那它的默认min.insync.replicas就是2；如果是Broker3当控制器后创建的，就是4。当前控制器是Broker3，但对已有的topic来说，该是什么值还是什么值，不会因为控制器变化而自动更新。

2. 针对新创建的Topic #

当你现在创建新topic，且没有手动指定min.insync.replicas时，控制器（也就是Broker3）会读取自身broker配置里的默认值（也就是4），作为这个新topic的min.insync.replicas默认值，然后把这个值写入集群的元数据存储（ZK或者KRaft）。之后所有broker处理这个topic的请求时，都会用这个存在元数据里的topic级参数来做ISR校验，和其他broker的配置无关。

额外补充：请求处理时的校验逻辑 #

不管哪个broker处理生产者的请求（比如设置了acks=all），它都会去读取该topic在元数据里的min.insync.replicas值，而不是用自己broker的默认配置。也就是说，哪怕Broker1的默认配置是2，它处理某个min.insync.replicas=4的topic请求时，依然会要求ISR的数量至少是4才会返回成功。

总结 #

• 已存在topic：看自身配置，和当前控制器、其他broker配置无关；
• 新创建topic：默认值取当前控制器（Broker3）的配置值4；
• 所有请求的校验逻辑，都是基于topic自身的min.insync.replicas配置。

内容的提问来源于stack exchange，提问作者Nag