kafka与zk的leader选举的混沌不清

在kafka中，同个topic下的partition分布在多个broker中，topic下的partitions使用zookeeper进行分布式协调，可以说kafka与zk是牢牢联系在一起的。但其中，都存在leader选举、主从复制、同步有效个数（zk是超过一半，kafka则是在isr列表中个数），在学习的初始造成一些混淆与困惑。

认清zookeeper的leader选举的内与外

内
一般书籍或者网络上提到zk的leader选举，指是的zk集群内部多台zk机器的选举。zk集群中多台机器都会存在全量数据，有且只有一台机器是zk集群的leader，负责zk集群的写入，事务提交等工作。但leader宕机时候，zk切换到leader选举模式（平时是数据同步，即进行数据复制模式），每台机器都根据zxid和serverId投票出新的leader。zk在cap理论模型中，支持的是ap，也即会存在不可用的风险，这也是被诟病作为服务治理配置中心的缺点。且客户端在连接的zk节点（客户端可以连接zk集群中任何一台机器，读的时候在连接的机器上进行，写的时候由连接的机器转发到leader进行）断开时候，客户端重连新的zk机器，也只会选择zxid不小于当前客户端缓存的机器。

外
集群管理是zk输出给外部的能力，如kafka的partitions副本使用zk提供的集群管理功能，达到多个partition副本间能进行leader选举。外部的机器在kafka中的体现就是一个目录下的多个znode节点，如下图所示