分布式协调服务zookeeper复习（分布式笔记）

zookeeper集群角色

一、 leader

  leader是zookeeper集群的核心，是事务请求的唯一调度者和处理者，保证集群事务处理的顺序性，集群内部各个服务器的调度者

二、 follower

1. 处理客户端非事务请求，以及转发事务请求给leader服务器（事务请求是指对数据进行了变动的请求，如：增、删、改）
2. 参与事务请求提议的投票（客户端的一个事务请求，需要半数服务器投票通过以后才能通知leader提交，leader会发起一个提案，要求follower投票）
3. 参与leader选举的投票

三、 observer

  观察zookeeper集群中最新状态的变化，并将这些状态同步到observer服务器上。由于observer既不参与事务请求提议的投票，又不参与leader选举的投票，所以增加observer服务器不会影响集群中事务处理能力，同时还能提升集群的非事务处理能力。
Tips：zookeeper集群节点个数为什么最好是2n+1？
  zookeeper集群一大特性是只要集群中半数以上（超过一半）的节点存活，集群就可以正常提供服务，所以第一点好处是 防止单点故障，比如：集群中只有2台服务器，若其中1台挂掉，集群则停止对外提供服务，而如果集群中有3台服务器，若其中1台挂掉，集群则重新选主，继续对外提供服务。
  第二点好处是，2n+1台和2n+2台机器的容灾能力相同，都是允许n台机器宕机，本着节约的宗旨，一般选择部署2n+1台机器，比如：3台服务器，至少2台正常运行才行（3的半数为1.5，半数以上最少为2），正常运行可以允许1台服务器挂掉；4台服务器，至少3台正常运行才行（4的半数为2，半数以上最少为3），正常运行可以允许1台服务器挂掉

leader选举

一、概述

  在ZooKeeper中，提供了三种Leader选举的算法，分别是LeaderElection、UDP版本的FastLeaderElection 、TCP版本的FastLeaderElection（默认）。
  可以通过在配置文件zoo.cfg中使用electionAlg属性来指定，分别使用数字0~3来表示。 0代表LeaderElection，这是一种纯UDP实现的Leader选举算法；1代表UDP版本的FastLeaderElection，并且是非授权模式；2也代表UDP版本的FastLeaderElection，但使用授权模式；3代表TCP版本的FastLeaderElection。值得一提的是，从3.4.0版本开始，ZooKeeper废弃了0、1、2这三种Leader选举算法，只保留了TCP版本的FastLeaderElection选举算法。

二、选举算法核心

serverid：在配置server集群的时候，给定服务器的标识id（myid）
zxid：服务器在运行时产生的数据ID， zxid的值越大，表示数据越新，越可能被选上
Epoch：选举的轮数
server的四种状态：Looking（master未确定时，机器都会处于looking观望状态）、Following（跟随状态）、Observering（观察状态）、Leading（领导状态）

1. 所有在集群中的server都会推荐自己为leader，然后把（myid、zxid、epoch）作为广播信息，广播给集群中的其他server, 然后等待其他服务器返回；
2. 每个服务器都会接收来自集群中的其他服务器的投票。集群中的每个服务器在接受到投票后，开始判断投票的有效性；
   a) 判断逻辑时钟(Epoch) ，如果Epoch大于自己当前的Epoch，说明自己保存的Epoch是过期。更新Epoch，同时clear其他服务器发送过来的选举数据。判断是否需要更新当前自己的选举情况；
   b) 如果Epoch小于目前的Epoch，说明对方的epoch过期了，也就意味着对方服务器的选举轮数是过期的。这个时候，只需要将自己的信息发送给对方
   c) 如果sid等于目前的sid，根据规则来判断是否有资格获得leader
   
   Zookeeper中leader选举的详细分析可以查看下述博客：
   https://www.cnblogs.com/leesf456/p/6107600.html

ZAB协议

一、什么是ZAB协议

  ZAB（Zookeeper atomic broadcast）协议是为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议，主要用来解决在分布式网络环境下，各个服务器如何达成一致，保证数据的最终一致性。

二、zab协议的作用

1. 在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性
2. zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，把数据的状态变更以事务请求的形式广播到其他的节点
3. zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更
4. 所有的事务请求必须由全局唯一的服务器来协调处理，这个服务器叫leader，其他的叫follower，leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点，再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息

zab协议的工作原理

一、什么情况下zab协议会进入崩溃恢复模式

1. 当服务器启动时；
2. leader服务器出现网络中断、崩溃或者重启的情况；
3. 集群中已经不存在过半的服务器与该leader保持正常通信

二、zab协议进入崩溃恢复模式会做什么

a) 当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader，当新的leader选举出来以后，如果集群中已经有过半机器完成了leader服务器的状态同步（数据同步），退出崩溃恢复，进入消息广播模式；
b) 当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入数据恢复模式，找到leader进行数据同步