风

如果topic没有副本，是会导致消费不了和生产不了的（超过半数）。
应该是断断续续的，否则是会踢出的。
你可以通过命令查看下集群的状态。

## 查询集群描述
bin/kafka-topics.sh --describe --zookeeper 127.0.0.1:2181

命令来自：kafka命令大全

现在看到的现象是，一个节点出现大量CLOSE_WAIT状态连接，其它正常节点日志一直报“java.net.SocketTimeoutException: Failed to connect within 30000 ms”，3个broker的进程都在也没有宕机，但是整个集群生产者发不了消息，消费者消费不了消息，处于不可用状态，只有当kill调有问题的节点后，整个集群才能恢复正常的生产消费状态，我是想问，在这种情况下，问题节点与其它正常节点的通讯一直是超时，为什么kafka集群不把出问题的节点从集群中剔除，让整个集群恢复正常？

kafka某台宕机，只影响所在topic分区leader。

还想问下大神，为什么kafka集群中某个节点出现大量CLOSE_WAIT状态连接，导致其他节点与该节点通讯不了，日志一直报如下异常：

java.net.SocketTimeoutException: Failed to connect within 30000 ms
        at kafka.server.ReplicaFetcherBlockingSend.sendRequest(ReplicaFetcherBlockingSend.scala:93)
        at org.apache.kafka.clients.NetworkClientUtils.sendAndReceive(NetworkClientUtils.java:97)
        at kafka.server.ReplicaFetcherBlockingSend.sendRequest(ReplicaFetcherBlockingSend.scala:97)
        at kafka.server.ReplicaFetcherThread.fetchFromLeader(ReplicaFetcherThread.scala:190)
        at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:241)
        at kafka.server.AbstractFetcherThread.$anonfun$maybeFetch$3(AbstractFetcherThread.scala:130)
        at kafka.server.AbstractFetcherThread.$anonfun$maybeFetch$3$adapted(AbstractFetcherThread.scala:129)
        at scala.Option.foreach(Option.scala:257)
        at kafka.server.AbstractFetcherThread.maybeFetch(AbstractFetcherThread.scala:129)
        at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:111)
        at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:82)

此时为什么kafka集群，不在多次尝试与该节点进行通讯超时时，不把该节点从集群中剔除？其它正常节点还要一直不断的进行连接尝试，由于一直连接超时，还会导致整个集群不可用，要是kafka集群主动在多次节点间的心跳超时，就将该节点判断为故障，并将该节点从集群中剔除，整个集群就可以恢复正常，后面再又人工去重启故障节点，不是更好吗？请问这样的机制是可以通过kafka的哪些参数配置来实现还是kafka没有这样的判断机制？

问题参照：https://www.orchome.com/1085
与该个问题应该是属于同一个问题，出问题的节点上有大量CLOSE_WAIT状态连接未关闭，导致该节点与其他节点的TCP通讯受阻，只能通过重启节点解决