Kafka能否写入Follower节点 解决Leader网络不通时消息投递问题

问题背景 #

• 生产环境存在一类偶发故障：某分区Leader副本所在Broker进程运行正常，但生产者侧到该Broker的网络链路中断，导致生产者无法访问Leader节点；由于Leader存活状态正常，集群不会自动触发Leader选举，写入直接失败。
• 该场景可通过防火墙封禁端口/主机的方式复现，本次测试使用的集群部署如下：

h0: 运行7个Broker实例，端口范围9092-9098
h1: 运行3个Broker实例，端口范围9092-9094
h2: 运行3个Broker实例，端口范围9092-9094
h3: 运行3个Broker实例，端口范围9092-9094

• 复现操作：封禁生产者侧到目标节点9092端口的出方向流量，最终观测到约25%的消息写入报错，结果符合预期。
• 实际生产中观测到这类单边网络故障的持续时间最长可达5分钟，需要确认是否有可行方案，保障该场景下消息可以正常写入Kafka集群。

解答 #

首先给出明确结论：原生Kafka不支持直接向Follower节点写入数据。所有生产请求必须发往分区对应的Leader副本处理，这是Kafka副本一致性设计的核心规则，本质是为了避免多节点写入带来的顺序冲突、数据不一致问题，不要尝试修改源码绕开这个限制，会直接破坏副本同步逻辑，引发数据丢失、乱序等严重问题。

针对你遇到的「生产者到Leader的链路断了，但Leader和集群其他节点通信正常、不触发自动选举」的场景，有几个可落地的方案，按改造成本从低到高排列：

• 客户端参数调优
  调整生产者端配置，缩短故障影响窗口：
  • 适当调低metadata.max.age.ms，从默认的300000（5分钟）降到60000-120000（1-2分钟），强制客户端定期刷新集群元数据，配合Broker端的定期优先副本选举，绕开不可达的Leader节点
  • 配置合理的重试参数：设置retries为大于3的值，retry.backoff.ms设为1000左右，给链路恢复和Leader切换留出重试窗口
  • 调低reconnect.backoff.ms和reconnect.backoff.max.ms，加快故障节点的连接失败判定速度
    这个方案改造成本最低，但只能把故障影响时间从5分钟缩短到1-2分钟，做不到秒级恢复。
• 部署四层代理做流量转发
  在生产者同网络域部署LVS、HAProxy这类四层TCP代理，生产者所有请求都发往代理，由代理做后端Broker的健康检查，一旦发现到某个Broker的链路不通，自动切断到该节点的转发，触发集群快速感知异常、选举新的Leader，故障恢复时间可以控制在10秒以内。
• 升级集群版本+启用KRaft模式
  把集群升级到2.8以上版本，启用KRaft共识协议替换原有的ZooKeeper模式：KRaft模式下的故障检测粒度更细，除了检测Broker进程存活，还会结合客户端连接成功率、副本同步延迟等指标判定节点可达性，一旦发现Leader节点对生产者侧不可达，会主动从ISR列表中选举可达的Follower作为新Leader，切换时间通常在3-5秒，不需要额外部署代理层。如果配合机架感知配置，把副本分散在不同交换机/可用区，同时设置min.insync.replicas=2、关闭unclean选举，就能在保证数据不丢的前提下，把这类单边网络故障的影响降到最低。

注意：Kafka 2.4之后推出的Follower Fetching能力，仅允许消费者从就近的Follower副本读数据，并没有开放Follower写入的能力，不要混淆这两个特性。

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