在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節點，如下圖所示
而上圖所示的數據，在每個zk的集羣節點機器上，都會冗餘存儲。kafka使用的leader選舉並非是zk自身用於選舉zk leader節點的方法（這是zk集羣內部的能力，對於框架使用者不需要了解），而是使用類似zk提供的分佈式鎖能力，kafka各個副本節點只會有一個當選leader，當leader釋放或者宕機，其他副本節點再重新當選leader。
zk與kafka數據同步的作用對象
zab協議是在zk集羣節點上用於同步節點數據，所以同步的是同一個znode節點上的數據，比如將上圖值爲的“leader”的節點數據同步到集羣中其他機器上的，同個目錄結構上的”leader",使用類似兩階段提交的方式，由leader推行推送控制。
而kafka的主從同步是副本之間的，在zk中即是上圖的“leader”節點將數據複製到“follower1”節點，不同的節點中複製不受zk管控，而且數據也不會存在zk中。kafka使用follower主動拉取leader的方式，定義isr列表進行同步，所以針對的是不同的znode之間的數據同步。
cursor提供的leader選舉的兩種方式
實際應用開發中使用cursor框架作爲zk的客戶端，提供了兩種方式的leader選舉
- leaderLatch
類似於java的countDownLatch，只有一個節點選中爲leader，其他的節點處於await方法的阻塞中，當調用close或者失效時候斷開給其他節點 - leaderElection
每個節點都能當選leader，當選後調用節點的takeLeadership方法，方法調用完後就會釋放leader角色，如果希望能繼續持有leader角色，就要寫個死循環。該方法能對於領導權進行控制，在適當時候可以進行釋放，相對於前者有更大的領導控制權（前者是當選後通知，其他一直處於阻塞）