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

没有更多推荐了,返回首页