1. zk主体框架
- leader: 将接收的所有写请求同步给所有follower，若超过半数同意则发送更改；
- follower: 可处理读请求，将收到的写请求转发给leader，若leader挂了则follower可以参与选举，可处理所有读请求；
- observer: 可处理读请求，亦将写请求转发给leader；
- myid: 任何类型的node都有myid，是不能重复的；
- maxid: 每个node都有maxid用于标识节点中最后一个数据的编号（大多数情况下这个值是一致的）；
- zxid: 表示数据的更新程度，越大越新（类似maxid）；
- epoch: 纪元用于防止脑裂，看谁epoch大谁是最新一轮的选举结果；
- sid：类似myid，每台zk的唯一标识符
2. zk选举机制
-
首次启动：假设共5台服务器
- 第1台启动后，发起一次选举，因为启动数未到一半，故而无法完成选举，node1保持looking状态；
- 第2台启动，再次发起选举，此时node1 & node2分别投给自己，然后各自交换投票信息。node1发现node2的myid大于自己当前投票的node，会将投票改成投给node2，现在node2共计2票，而node1获得0票。但由于得票未超半数，两个node都保持looking状态；
- 第3台启动，重复上述操作，node3得到3票，成功当选leader（leading状态），且node1，2，3都不再为looking状态，变成follower的角色（following状态），后续不再改他们的投票计划；
- 第4台启动，由于1 2 3都支持node3，所以node4改票为支持node3，所以node4也变为follower；
- 第5台和4一样，最终确认3号成为leader。
-
非第一次启动进行新选举：
- 若cluster中原本的leader存在，有node企图选举则会被告知已有leader，让该node与现leader建立连接同步状态即可；
- 若cluster中leader挂掉，则先对比epoch，再对比zxid谁大（类似maxid，看谁的数据新），最后对比sid谁大（类似myid）
3. zk在分布式集群中的作用
常见作用：分布式组件间的数据通信、集中式的元数据管理、服务发现/注册中心、HA自动选主 & 分布式锁
-
kafka中所用：
- 组件间数据通信，保持kafka不同节点间的通信（例如心跳）；
- 元数据管理: isr元数据更新，确认哪些kafka主题分区及时完成了数据同步；
- HA自动选主: kafka集群的controller选举，通过zk的watcher机制，其他节点观察controller的情况，随时准备抢占。
