Kafka集群分区副本设置为1，当分区所在broker宕掉引发的该分区不可用的问题

问题表象：业务进程中的kafka生产者线程报错：

put suc offset:-1 partition:1 topic: test_topic
org.apache.kafka.common.errors.TimeoutException:Expiring 13 record(s) for test_topic-1:3000 ms has passed since last append

于是查看kafka日志发现有如下告警：

[org.springframework.kafka.KafkaListenerEndpointContainer#0-0-C-1]WARN org.apache.kafka.clients.NetworkClient-[Consumer clientid=consumer-2,groupid=test_api] 1partitions have leader brokers without a matching llistener,includering[test_topic-]

意思像是该分区所对应的的broker失去监听了，失联了，所以怀疑是kafka某个节点有问题

于是查看topic信息发现

/kafka/bin/kafka-topics.sh --describe --zookeeper 192.168.1.108:2181 --topic test_topic

图片是粘的别人的，就是想贴个图表达个意思。发现partition1对应的leader为-1，Replicas:1003, Isr为空。

查看server.properties文件 找到broker.id=1003对应的节点，发现该节点宕调了，宕调的原因因环境而异，不再赘述，把这个节点拉起来后问题解决，查看分区1的信息leader:1003 Isr:1003,生产者线程也能正常将数据入到kafka中，至此问题解决。

这不由得让我们思考一个问题：不都称赞kafka的高可用性么，作者自己搭建的kafka集群也是由三个节点组成的，为什么一个节点挂了，整个分区就不能正常使用了呢，其实是因为作者使用了默认的topic分区副本数量：offsets.topic.replication.factor=1

这样会导致一个问题，如果分区副本数量为1，那副本信息只会在某一个broker节点存在，Isr也就是其自身，当这个节点挂了的时候，已经选举不出新的leader,导致分区不可用，leader:-1,所以这也正是生产环境一般会设置多个副本因子来保证高可用性（比如三个节点组成一个集群，副本数量为2，这样当任意一台节点丢失，kafka集群仍会正常工作）。

再贴盗图一张表达个意思，主要看Isr信息

以上纯属作者自证结论，如跟读者有意见分歧，欢迎指正讨论。

  欢迎大家私信博主，邀你进技术交流群