看起来你在测试Kafka高可用性的时候碰到了重启丢数据的问题，结合你的环境（1个ZK节点、2台Kafka Broker，主题副本数2），我来梳理几个最可能的原因以及对应的排查和解决办法：

1. 生产者消息确认机制配置不足 #

你发送消息时如果用了默认的acks=1，那消息只需要Leader Broker确认接收就会返回成功给生产者。如果此时你刚好重启这个Leader节点，消息还没来得及同步到Follower副本，这条消息就会永久丢失。

• 排查方式：检查你的生产者配置文件，确认acks参数的取值；如果是代码发送，看生产者初始化时是否指定了该参数。
• 修复方案：将生产者的acks参数设置为all（或-1），这会要求消息同步到所有处于「同步副本列表（ISR）」的节点后，才会向生产者返回成功确认。同时在Broker端设置min.insync.replicas=2（和你的主题副本数一致），确保只有当至少2个副本都同步了消息，生产者才能收到确认，从根源避免单节点重启导致的数据丢失。

2. 非同步副本被选举为Leader #

如果Broker配置中的unclean.leader.election.enable被设为true，当Leader节点意外下线时，Kafka可能会允许不在ISR列表里的Follower节点成为新Leader。这些节点没有同步Leader的最新数据，切换后未同步的消息就会丢失。

• 排查方式：查看Broker的server.log日志，搜索关键词Unclean leader election，确认是否发生了非ISR Leader选举；同时检查Broker配置文件中的unclean.leader.election.enable参数值。
• 修复方案：确保unclean.leader.election.enable=false（这也是Kafka的默认配置，但最好手动确认），这样只有ISR列表里的副本才能被选举为Leader，避免数据丢失。另外可以适当调小zookeeper.session.timeout.ms参数，让ZK更快感知Broker的下线状态，缩短可能出现不一致的窗口。

3. 测试流程中同步等待时间不足 #

如果你发送完Hello后立刻重启Leader节点，哪怕配置了acks=all，也可能因为消息还没完成跨节点同步就触发了重启，导致数据丢失（测试场景下操作间隔短，这种概率会更高）。

• 排查方式：修改测试流程，发送消息后等待3-5秒再执行重启操作，看是否还会出现数据丢失的情况。
• 修复方案：测试时增加足够的同步等待时间；生产环境中可以通过监控under_replicated_partitions指标，确认所有副本都处于同步状态后再进行节点维护操作。

4. 主题的最小同步副本数配置不匹配 #

如果你的主题min.insync.replicas参数设置小于副本数（比如设为1），那么即使只有Leader节点同步了消息，生产者也能收到成功确认。此时重启Leader节点，未同步到Follower的消息就会丢失。

• 排查方式：用Kafka命令行工具查看主题配置：

  kafka-topics.sh --describe --topic <你的测试主题名> --bootstrap-server <kafka-broker地址:端口>
  

  在输出中找到min.insync.replicas的取值。
• 修复方案：通过命令行修改主题的最小同步副本数：

  kafka-configs.sh --alter --topic <你的测试主题名> --add-config min.insync.replicas=2 --bootstrap-server <kafka-broker地址:端口>
  

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