zookeeper学习笔记2

一、zookeeper集群的特点

zookeeper集群中有三种角色，一个领导者 leader，多个跟随者 follower，还有observer观察者（跟follower 不同的是它不参与leader的选举）。集群中只要有半数以上的节点存活，集群就可以正常提供服务，所以zookeeper 适合部署奇数台服务器作为集群。写操作只能由leader来进行，follower进行数据的读操作，每个server 保存一份相同的数据副本，不管client客户端从哪台服务器读取数据都是一样的。同一个client发送的请求按照发送的顺序先后依次执行。数据的更新具有原子性，要么全部成功要么全部失败。zookeeper的节点中数据同步有时间延迟，但是同步速度很快，在一定时间范围内client都可以读到最新的数据。

二、zab协议

全称是zookeeper atomic broadcast 协议，是zookeeper在分布式架构的服务中为了确保事务的一致性而产生的一种原子性广播协议，它支持崩溃数据恢复和消息广播。

zookeeper服务的server节点有几种不同的状态：looking（当集群中没有节点时，集群会进入这种状态，为了查找或者选举leader）、leading（对应着leader角色）、following（对应着follower角色）、observing（对应着observer 角色），所以不同的节点是根据自己当前的状态来判断自己是什么角色。

zookeeper还给zab定义了四种不同的状态：1，election，集群进入选举状态，选出一个leader。2、discovery，server进行发现，去连接leader节点，响应leader的心跳，并检测leader角色是否需要更改，经过此步骤之后leader才能执行事务。3、synchronization，进入同步状态，集群中的每个节点都确定leader 以后，同步leader中的数据，这样来保证集群中数据的一致性。4、broadcast，进入广播状态，集群开始对外提供服务。

  zookeeper中事务提交的过程，首先一个客户端任意连接一个server端点，如果是要进行读操作，那直接从当前节点中读取数据，如果是要进行写操作，就会转到leader端提供服务，客户端发送一个写请求后，leader节点生成一个事务proposal，同时赋予一个zxid事务id，然后leader开始广播该事务，leader 为每一个follower都维护了一个FIFO的队列，来实现异步非阻塞方式处理消息，扔到队列中后，每个follower开始去读取这条事务 ，并把它写入到自己的本地磁盘中，写入成功后返回一个ack确认给leader，leader进行反馈统计，如果超过半数的follower都成功返回了ack信号，那么leader开始广播提交事务（commit），当然自己先去把事务提交了，最后每个follower都把事务提交。

  依次介绍下上述出现的关键词，zxid全局事务id，是zab协议为了保证事务顺序的一致性规定的一种递增的事务id号，是一种long类型的数据，总共有64位，高32位是epoch，就类似是广播该proposalleader的版本号，可以用来确定leader是否发生了变化，当有leader被新选举出来以后，这个epoch就会加1，代表了一个leader的时期，后32位是counter计数器，就是一个随着事务proposal增加而递增的一个数字。

  zab包含两种基本模式：1，崩溃数据恢复  2，消息原子广播

  首先说一下奔溃数据恢复，那么就会想到什么时候会执行或者说进行崩溃数据恢复模式，一、首先是集群首次启动的时候，这个时候还没有选举出leader，需要先选出了leader以后再进行数据同步，当有过半的follower节点与leader连接上完成数据同步之后，才会退出这个模式。二、就是当集群服务器出现故障，leader挂掉了，暂时无法对外提供服务，那么也会进行数据恢复工作，重新选举leader再同步数据。

  消息广播就是上面提到的，事务提交的一个过程，来继续讨论下这两种模式的切换条件或者说是时机，数据恢复转到消息广播就是上面提到的当有半数的follower节点已经完成与leader节点的数据同步之后就表明我这个集群现在能够对外提供服务了，进行转换。而消息广播转到数据恢复就是当集群出现故障，超过半数的节点都挂掉了，或者说是出现了网络中断，产生了leader与其他节点出现了网络分区，无法进行同步一致性，就会进入数据恢复模式，重新选举leader进行同步。

  在上述的过程中有两个地方可能会出现问题，第一个就是已经被处理的消息不能丢失，就是加入leader在收到过半数的ack确认之后，需要提交了，在提交的期间leader挂掉了，就会出现follower1已经提交了，而follower2并没有收到提交命令，而客户端也收到了事务成功的返回响应，这样就造成了其他节点数据的不一致。  第二个是当leader收到一个请求生成proposal以后，它就挂掉了，经过重新选主以后，以前的leader重新启动恢复了，但是还保存着上次leader的proposal信息，就跟整个集群不一致了，这个老的proposal是需要删除的。

  针对这两个问题zab首先规定了选举的规则：首先所有节点都先投票自己为leader，然后比较zxid 的epoch，谁的epoch大就选谁，如果epoch一样就比较counter的大小，谁的counter大就说明数据比较完整。如果还一样就比较serverId，这个是在配置集群的时候为每一个服务器节点设置的数值，编号越大就选谁，所以在设置serverId的时候就可以把性能比较好的服务器设置的高一点，提高集群的效率。   为啥要设置这样的规则呢，因为这样选举出来的leader拥有最大的zxid，就意思是它具有最新的事务proposal，因为前面提交的时候，肯定是有超过半数的节点成功的执行了这条事务，所以选择它做为leader，可以把集群中的数据跟新到最新版本。

其次就是对zxid为啥这样的规定，增加一个事务zxid的counter值就加1，新选出一个‘leader，epoch就加1，然后新选出leader以后，会把自己的counter32位清零，既然它当选了leader，那么那个老的leader的zxid肯定比他小，所以我就规定让老leader作为follower连接到我以后，你就把你没执行的事务proposal全部删掉，这个就作废了。

经过这样的设计，可以保证集群在发生前述的两个问题后，集群还能保证自己应有的可用性与一致性。

在广播的时候还需要保证一致性，这里的一致性指的是全局有序和逻辑有序，全局有序就是根据事务的发布顺序，赋予顺序的zxid号值，这个全局唯一，切不可改变。逻辑一致性就是比如说我要创建节点，必须先创建了/chen，才能继续创建/chen/zhi ，有先后的父子节点的顺序。在队列中执行事务时也会进行判断并调整顺序。