深入分析zookeeper的实现原理

zookeeper 的由来

缺少一个分布式协调机制:  zookeeper

          上面这个架构下 zookeeper ，可以用来解决 task 执 行问题，各个服务先去 zookeeper 上去注册节点，然后获 得权限以后再来访问 task。

zookeeper 的设计猜想

       zookeeper 主要是解决分布式环境下的服务协调问题而产 生的，如果我们要去实现一个 zookeeper 这样的中间件， 我们需要做什么?

   1、防止单点故障

          这个中间件需要考虑到集群,而且这个集群 ，还需要分摊客户端的请求流量

   2 、每个节点都能接 收到请求，并且每个节点的数据都必须要保持一致

           所以这个集群中涉及到数据同步以及会存在 leader 节点

  3、如何在这些节点中选举出 leader 节点，以及 leader 挂了以后，如何恢复呢?

          zookeeper 用了基于 paxos 理论所衍生出来 的 ZAB 协议

    4、leader 节点如何和其他节点保证数据一致性，并且要求 是强一致的。在分布式系统中，每一个机器节点虽然都 能够明确知道自己进行的事务操作过程是成功和失败， 但是却无法直接获取其他分布式节点的操作结果

         所以 当一个事务操作涉及到跨节点的时候，就需要用到分布 式事务，分布式事务的数据一致性协议有 2PC 协议和 3PC 协议。

          基于这些猜想，我们基本上知道 zookeeper 为什么要用到 zab 理论来做选举、为什么要做集群、为什么要用到分布 式事务来实现数据一致性了。接下来我们逐步去剖析 zookeeper 里面的这些内容   

   关于 2PC 提交

      (Two Phase Commitment Protocol)当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的 ACID 特性，就需要引入一个“协调者”(TM)来统一调度所有分 布式节点的执行逻辑，这些被调度的分布式节点被称为 AP。 TM 负责调度 AP 的行为，并最终决定这些 AP 是否要把事 务真正进行提交;因为整个事务是分为两个阶段提交，所 以叫 2pc