zookeeper 、kafka leader选举

拼搏现实的明天。 2022-05-25 07:00 189阅读 0赞

# 一、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