zookeeper 、kafka leader选举

一、Zookeeper的基本操作

1、zookeeper四种节点类型： PERSIST, PERSIST_SEQUENTIAL, EPHEMERAL, EPHEMERAL_SEQUENTIAL

可分为两种维度：

1. 可持久化：机器重启后节点任然存在，PERSIST, PERSIST_SEQUENTIAL。
2. 顺序节点：创建相同的节点，顺序节点会在后面添加序号EPHEMERAL, EPHEMERAL_SEQUENTIAL。

2、可注册Watch操作

1. Created event: Enabled with a call to exists 创建节点
2. Deleted event: Enabled with a call to exists, getData, and getChildren 删除节点
3. Child event: Enabled with a call to getChildren 子节点被创建与删除

3、Watch特征

1. 客户端先得到通知再得到数据
2. Watch被fire后即取消,不会再Watch后续变化，如果需要继续监控，就需要再次注册，但是在fire后、注册前节点发生变化是不会被监控到的。

二、基于Zookeeper的Leader Election（选举）

1、抢注Leader节点——非公平模式

1. 列表内容
2. 创建Leader父节点,如 /chroot，或者’/’，并将其设置为persist节点
3. 各客户端通过在/chroot下创建Leader节点,如/chroot/leader,来竞争Leader。该节点应被设置为ephemeral（临时节点，并不是顺序节点）
4. 若某创建Leader节点成功,则该客户端成功竞选为Leader
5. 若创建Leader节点失败,则竞选Leader失败,在/chroot/leader节点上注册exist的watch,一旦该节点被删除则获
   得通知
6. Leader可通过删除Leader节点来放弃Leader
7. 如果Leader宕机,由于Leader节点被设置为ephemeral,Leader节点会自行删除。而其它节点由于在Leader节点
   上注册了watch,故可得到通知,参与下一轮竞选,从而保证总有客户端以Leader角色工作

2、先到先得,后者监视前者——公平模式

1. 创建Leader父节点,如 /chroot,并将其设置为persist节点
2. 各客户端通过在/chroot下创建Leader节点,如/chroot/leader,来竞争Leader。该节点应被设置为ephemeral_sequential
3. 客户端通过getChildren方法获取/chroot/下所有子节点,如果其注册的节点的id在所有子节点中最小,则当前客户端竞选Leader成功
4. 否则,在前面一个节点上注册watch,一旦前者被删除,则它得到通知,返回step 3(并不能直接认为自己成为新Leader,因为可能前面的节点只是宕机了)
5. Leader节点可通过自行删除自己创建的节点以放弃Leader

三、Leader Election在Curator中的实现

1、LeaderLatch

1. 竞选为Leader后,不可自行放弃领导权
2. 只能通过close方法放弃领导权
3. 强烈建议增加ConnectionStateListener,当连接SUSPENDED或者LOST时视为丢失领导权
4. 可通过await方法等待成功获取领导权,并可加入timeout
5. 可通过hasLeadership方法判断是否为Leader
6. 可通过getLeader方法获取当前Leader
7. 可通过getParticipants方法获取当前竞选Leader的参与方

2、LeaderSelector

1. 竞选Leader成功后回调takeLeadership方法
2. 可在takeLeadership方法中实现业务逻辑
3. 一旦takeLeadership方法返回,即视为放弃领导权
4. 可通过autoRequeue方法循环获取领导权
5. 可通过hasLeadership方法判断是否为Leader
6. 可通过getLeader方法获取当前Leader
7. 可通过getParticipants方法获取当前竞选Leader的参与方

四、Kafka“各自为政”Leader Election（最先的）

1、“各自为政”Leader Election： 每个Partition的多个Replica同时竞争Leader
2、优点：实现简单
3、缺点

1. Herd Effect：生产环境当中，服务器很多，如果有一个宕机，会有太多的follower去竞争leader
2. Zookeeper负载过重
3. Latency较大

Kafka基于Controller的Leader Election（0.8.2版本后的）

1、基于Controller的Leader Election

1. 整个集群中选举出一个Broker作为Controller
2. Controller为所有Topic的所有Partition指定Leader及Follower

2、优点

1. 极大缓解Herd Effect问题
2. 减轻Zookeeper负载
3. Controller与Leader及Follower间通过RPC通信,高效且实时

3、缺点

1. 引入Controller增加了复杂度
2. 需要考虑Controller的Failover