场景复现：
写在前面的话，业务组内研发童鞋碰到了这样一个问题，反复尝试并研究，包括不限于改Kafka，主题创建删除，Zookeeper配置信息重启服务等等，于是我们来一起看看...
Ok，Now，我们还是先来一步步分析它并解决它，依然以”化解“的方式进行，我们先来看看业务进程中线程报错信息：
org.apache.kafka.clients.NetworkClient :
[Consumer clientId=consumer-1, groupId=xxxx-center] 1 partitions have leader brokers without a matching listener, including [xxxx-xxxx-xxxx-message-0]
假设猜想：
从字面意思来看，当前分区所对应的的broker失去监听，为什么监听不到？怀疑是Kafka某个节点有问题-失联-假死？
思考过程：
从这个表象来看，某台机器有过宕机事件，宕机原因因环境而异，但Kafka的高可用性HA我们是耳熟能详的，为啥我们搭建的Kafka集群由多个节点组成，但其中某个节点宕掉，整个分区就不能正常使用-消费者端无法订阅到消息。
首先，我们来看下Kafka的配置信息：[root@xx-xx-xxx-xx kafka_2.11-2.1.1]# nohup bin/kafka-server-start.sh config/server.properties &
这里使用了默认的topic分区副本数量：offsets.topic.replication.factor=1，当分区副本数量为1，则副本信息只会存在某一个broker节点，Isr即其自身。
这很容易出现单点故障，当当前节点挂了的时候，选举不出新的leader，导致分区不可用。在生产环境的话，可设置多个副本因子来保证高可用性（比如三个节点组成一个集群，副本数量为2，这样当任意一台节点丢失，kafka集群仍会正常工作Working...）。
解决方案：
当然，把这个宕掉的节点拉起来，查看该分区的信息leader:xxxx Isr:xxxx，保障生产者线程也能正常将数据入发送到Kafka中，消费者线程正常订阅到消息。
我们这里分布式协调服务采用的是Zookeeper，当Kafka某个broker节点宕调后，其实我们可以在Zookeeper中还是有迹可循的，Kafka集群的一些重要信息都记录在Zookeeper中。
首先，我们来查看topic主题都有哪些，查询topic列表，进入kafka目录：
bin/kafka-topics.sh --list --zookeeper localhost:2181
然后，查询topic日志内容，跟业务进程中线程报错信息一致，进入kafka目录：
bin/kafka-console-consumer.sh --bootstrap-server xx.xx.xxx.xx:9092 --topic xxxx-xxxx-xxxx-message --from-beginning
接下来，查看当前topic详细信息，进入kafka目录：
bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic xxxx-xxxx-xxxx-message
在Kafka的server.properties配置文件中指定的broker.id=71已不在其中--从主题详细信息中，我们可以看到Partition，Leader，Replicas，Isr都为0...
接着，我们还是进入Zookeeper，查一下踪迹，进入Zookeeper目录：
./zkCli.sh -server localhost:2181
输入 ls /，查看到了Zookeeper中存储了brokers信息，
输入 ls /brokers/ids，查看到ids [0]，
这里broker.id的指定：在server.properties中修改broker.id可为当前机器后缀数值，不要超过其范围，保持日志中一致的话，
cd /home/user/kafka/logs，同样修改meta.properties文件，
而输入 ls /brokers/topics/xxxx-xxxx-xxxx-message/partitions/0/state，继续查看当前topic分区状态，
果不其然，已验证了之前的猜想，当前Broker节点下该分区没有查询到任何可用信息...
我们把这个宕掉的节点拉起来后，按上述步骤查看当前分区信息，这里我们上俩张成功后的图，保障了生产者线程也能正常将数据入发送到Kafka中，消费者线程也能正常订阅到消息。
