Zookeeper学习心得

Zookeeper 学习心得
提起Zookeeper,大家就会想到分布式架构的系统，而分布式系统中都是基于CAP原则来实现的，下面就先介绍一下CAP原则
CAP原则
1.可用性 Availability
可用性是在某个考察时间，系统能够正常运行的概率或时间占有率期望值
2．一致性（强一致性）Consistency
数据一致性， 强一致性： 两个数据库的数据一定是相同的才会对外展示
3. 分区容错性Partition tolerance
分区容错性是指系统能够容忍节点之间的网络通信的故障

4.特    点
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡

一个分布式系统往往是在可用性与一致性之间平衡。大多都是在保证一致性的前提下，尽可能地提高系统的整体可用性。常见的有二阶段提交（2PC）、三阶段提交（3PC）、Paxos
一致性协议
1.PC二阶段提交
1.PC二阶段提交：
（1）准备阶段 ，事务管理器给每一个参与者发送消息，参与者在本地执行事务，写入日志
（2）提交阶段（当所有的参与者返回成功以后提交） 中断事务：发送回滚结果，每个节点都会回滚并且给事务管理器发送一个状态，将事务回滚到提交之前
存在问题：
1. 阻塞问题： 事务管理器在发送消息，等待参与者反馈结果之前是阻塞的，不能干其他的事情
2. 单点问题： 如果事务管理器挂掉了，那么其他的参与者将不能够相互通讯
3. 脑裂导致数据不一致 ： 参与者挂掉了一个，那么事务管理器将不再能够接收到参与者的信息，导致数据不一致

2.PC三阶段提交：
    （1）  协调者像参与者发送一个询问：能否执行事务操作 ， 参与者返回一个状态（能否进行事务操作）
	（2） 如果一阶段返回状态都是yes，执行事务，并把结果返回给协调者， 如果一阶段返回有no，或者有未响应的，则执行者发起一个请求，中断事务。如果参与者收不到执行者的请求，则超时也会中断事务
    （3）如果前两个阶段确定没有问题了，则协调者会发送一个请求，让参与者提交他们的事务，
	 然后参与者像协调者再次发送事务提交的状态，没有问题以后，协调者提交自己的事务  ，如果有了问题以后，则协调者发起回滚，参与者也开始回滚
 存在问题： 解决了PC2的阻塞和单点问题，但是脑裂导致数据不一致的问题没法解决	 

3.Paxos算法 
 重要概念：半数概念：少数服从多数，    在分布式中，如果产生网络异常，或者服务器挂了的情况下，可以快速的在集群内部对某一个数据的值达成一致，
  并且不管发生任何异常，都不会破坏整个系统的一致性。	
  四个角色 
     1.client ：产生提案者   
	 2.proposer：提案者 ****
	 3.acceptor：决策者*****
	 4.learners：学习者 
阶段：
（1）prepare阶段：准备解决阶段 

(a) Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。Pareper（N）
(b)如果一个Acceptor收到一个编号为N的Prepare请求，如果小于它已经响应过的请求，则拒绝，不回应或回复error。
若N大于该Acceptor已经响应过的所有Prepare请求的编号（maxN），
那么它就会将它已经接受过（已经经过第二阶段accept的提案）的编号最大的提案
（如果有的话，如果还没有的accept提案的话返回{pok，null，null}）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。
已经接受请求以后，进入二阶段，没有被接受的请求，开始增加自己的编号，当编号大于N后，被接受，再进入二阶段。
（2） accept阶段：同意阶段
(a) 如果一个Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value（某个acceptor响应的它已经通过的{acceptN，acceptV}），如果响应中不包含任何提案，那么V就由Proposer自己决定。
(b) 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案。如果N小于Acceptor以及响应的prepare请求，则拒绝，不回应或回复error（当proposer没有收到过半的回应，那么他会重新进入第一阶段，递增提案号，重新提出prepare请求）。
在上面的运行过程中，每一个Proposer都有可能会产生多个提案。但只要每个Proposer都遵循如上述算法运行，就一定能保证算法执行的正确性。
Paxos算法活锁问题：两个提案者进行访问 决策者 ，导致决策者数量增加，一直不断的循环。 通过选取主Proposer，就可以保证Paxos算法的活性。选择一个主Proposer，并规定只有主Proposer才能提出议案。这样一来，只要主Proposer和过半的Acceptor能够正常进行网络通信，那么肯定会有一个提案被批准（第二阶段的accept），则可以解决死循环导致的活锁问题。

ZAB协议：  

不直接使用Paxos算法的原因 1.活锁问题， 2.全序问题，全序，不能决定执行的顺序，无法保证事务提交的顺序
Leader 收到事务操作请求以后，将请求发给所有的follower， follower进行响应，基于半数原则，过了半数，则代表同意，进行事务提交，
然后完成所有的follower的数据同步， 读请求，直接在Leader中读取并返回， 如果写请求发送到了follower上，则会转发给Leader，因为只有Leader才可以处理写请求。

zookeeper的三种角色：
 leader ：负责写的请求，发起投票 ，在follower投票过半数以后执行 
 follower：负责投票和读请求响应结果，将写请求转发到leader上面 
 observe： 负责协助follower处理读请求，本身没有投票权（为什么不增加follower？：增加follower，在leader提出写请求时，会增加leader和follower之间的通信效率，影响读写效率）
 
 zookeeper两种模式：
 恢复模式：  服务启动或者是现有的leader崩溃了，zk就会进入恢复状态，选举leader，选举完成以后，完成leader和其他机器的数据同步，当大多数的server和leader完成同步以后，恢复模式结束 
 
 广播模式：恢复模式结束以后，进入广播模式，在广播模式下，新加入的服务器会自动在leader中同步数据，leader在接受客户端发出的请求以后，会生成事务同步给其他的机器，有超过半数的follower同意该提案以后，提交事务，   follower要么赞成，要么放弃， 过半原则，赞成超过一半就提交事务。
 
 Leader选举机制：
  1. zookeeper集群中，只有超过了半数的服务器启动，服务才能够正常工作
  2.在集群正常工作之前，myid小的服务器会给myid大的服务器进行投票，持续到集群正常工作，选出Leader。
  3.选择出Leader以后，之前的服务器的状态就都会由looking转变为following,变成following以后不再投票，之后的服务器也都是following状态，启动的时候也会投票
  根据半数原则，会将原本投给自己得一票投给已经成为Leader的服务器一票。
   崩溃恢复规则：  在Leader挂掉以后，剩下的following会变成looking状态，在剩下的没有挂掉的looking中重新选举出一个looking变成新的Leader	  
   
 ZooKeeper启动流程解析： 
  （1）加载配置文件， con.cfg      
  （2）启动清除任务， 主要清除旧的快照和日志文件 
  （3）启动模式分为两种 ，分布式集群启动和单机启动
  
  ZooKeeper实现分布式锁 原理：有序临时节点+watch监听实现 
    为每一个执行的线程创建一个有序的临时节点，为了确保有序性，在创建完节点后，
	会重新获取所有的临时节点，再重新进行一次排序，排序过程中，每一个线程要判断
	自己临时节点是否是最小的，如果是最小的，则获得锁，执行相关操作，释放锁，
	如果不是最小的，会监听它的前一个节点，当它的前一个节点被删除时，它就会获得锁
ZooKeeper应用场景 
1.配置中心 
例如数据库，开关配置，统一在配置中心配置，项目启动时，回去读取配置文件信息，同时使用watcher监听，一旦节点信息发生改变，所有订阅
该节点的客户端都可以获取数据变更通知。
2.负载均衡 
  建立一个service节点， 在service下面添加服务器信息（IP地址），同时对service进行监听，在每一个服务启动的时候，
  在service下面创建相应的子节点，并在相应的子节点下面存入相关的服务器信息，我们在Zookeeper上面就可以获取每一个服务器
  的信息，然后根据这些信息定义一个负载均衡的算法，在每一个请求请求zookeeper的时候，可以从服务器中获取当前服务器列表，
  根据算法，选出一个服务器来处理请求。
3.命名服务 
 zookeeper中创建顺序节点就可以实现服务命名（唯一性），数字+服务类型 例如 type10001，所有客户端都会通过自己的任务类型来创建一个顺序节点
拼接type类型，形成全局唯一的ID。	 
4.DNS服务   
域名服务，就不用修改自己电脑环境下的Host文件来频繁更换域名和IP的对应关系 。  创建一个节点管理域名。   
       服务，下面对应域名（域名和IP，端口信息）
	   域名更变，每个应用都会在对应的域名节点下注册一个数据变更的watcher监听，一旦监听的域名节点更变，zk就会像所有的订阅的客户端发送
	   域名变更通知 
 5.集群管理 
  集群控制： 对集群中节点的操作与控制 
  集群监控：对集群节点运行状态的收集
   日常需求：希望知道集群中有多少机器在工作 ，
   对集群中每一台机器的运行状态进行收集，
   对集群中的机器进行上下线操作 
   实现原理：根据zk的临时节点和watcher机制来实现
  机器上下线：新增机器的时候，将Agent部署到新增的服务器上面，当Agent启动的时候，会向zk指定的节点下创建一个临时节点，完成节点的创建以后，
  zk加入新的节点以后就会通知所有的客户端，当这个机器启动或者关闭的时候，都会向所有的客户端发送请求 。
  机器监控：在机器运行过程中，Agent会定时将主机的状态信息写入到指定的节点，监控中心通过订阅这些节点的数据变化哎获取主机的运行信息。