我在测试Kafka集群容错性时，发现这样一个问题：
我搭建的kafka集群中包含3个节点，当我先随机杀掉两个节点时，第3个节点成为leader，整个集群仍然可用，当我再杀掉唯一的节点时，kafka集群不可用。
但是我发现应用程序的日志一直在重连最后宕机的leader，并没有重连之前两个宕机的节点。
然后，我恢复了先杀掉的两个kafka节点，此时kafka集群可用，但我发现kafka客户端仍然没有重连恢复的节点，而是一直保持与最后死掉leader的重连。
但是其他节点恢复后成为新的leader了，客户端也没有重连，也就造成了全部节点宕机进行恢复时，必须恢复最后宕机的leader，否则，kafka集群虽然已经可用，但是应用程序仍然无法正常使用。
不知道这个问题怎么解决。
因为leader的数据是最新的，备节点在没有成为leader前宕了，那如果它成为leader，就会有丢消息的风险。
参考：https://www.orchome.com/22
参考：unclean.leader.election.enable
不完全首领选举，kafka默认是激活的，这个我没有动，我想问的是，当kafka集群节点全部宕机后，为什么kafka客户端只会重连宕机前的leader，，而没有与其他节点尝试重连，如果在恢复kafka集群时，刚好之前宕机的leader服务器无法及时恢复，，而此时，kafka集群已经可用，但是，kafka客户端不会重连其他节点，就导致了应用程序仍然不可用，，，kafka客户端在重连时明显进行了区别对待，，，
在我看来，为了kafka集群的容错性和高可用，kafka客户端在全部节点宕机之后都应该进行尝试重连，以最快的速度保证当kafka集群可用时，生产者和消费者也能正常使用，但是，kafka客户端明显没有这样去处理，，，而是一直重连全部宕机前的leader，，而且是强制性的，，也没有给用户选择的余地
大神，可有良策！
你的答案