分布式（Zookeeper）基本概念

Posted 2021-04-13 悦码

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper包含一个简单的原语集，提供Java和C的接口。
ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。

             分布式基本概念

分布式架构：在集中式的系统环境中，可以简单通过事务(ACID)保证数据的一致性；而在分布式系统环境中，由于缺少全局时钟、故障无法避免等痛点，过去的方式不在适用，而适用新的CAP定理和BASE理论。
CAP定理
Consistency一致性：指数据在多个副本间是否能保持一致的特性。针对一个数据项的更新，所有用户都可以读取到最新的值，则系统被认为是强一致的。
Availablity可用性：指系统一直处于可用状态，对于每一个请求都能在单位时间内返回结果。
Partition tolerance分区容错性：分布式系统在遇到任何网络故障时，仍然可以对外提供满足一致性和可用性的服务，除非整个网络都出现故障。
该原理指出，一个分布式系统无法同时满足这三个基本需求，因此需要作出合理的选择。由于P是分布式系统的基础，那么核心就是平衡A和C，最常见的就是BASE理论。
BASE：其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，
Basically Available基本可用：指分布式系统出现不可知故障时，允许损失部分可用性，比如响应时间上的损失、功能上的损失（服务降级）。
Soft state软状态：允许系统中数据存在中间状态，即允许不同节点的数据副本之间进行数据同步时存在延时。
Eventually consistent最终一致性：需要保证最终数据保持一致，而不需要实时保证系统的强一致性。在实践中，最终一致性存在5中变种，因果一致性，读自己之所写，会话一致性，单调读一致性和单调写一致性。比如关系型数据库，常通过同步或一部的方式实现主备数据复制，其实主备之间就存在数据不一致，但其通过多次重试或认为数据修订等方式保证了数据最终一致性，算是一个经典案例。
一致性协议：提到一致性协议，最基础的就是2PC（Two-Phase Commit protocol）两阶段提交协议，绝大多数的关系型数据库都是采用的2PC来完成分布式事务处理的。
2PC的流程：提交事务阶段，包括事务询问、执行事务、各参与者向协调者反馈事务询问的响应等步骤；执行事务阶段，包含两种情况，成功时执行事务提交，包括发送提交请求、事务提交、反馈事务提交结果、完成事务等步骤，而失败时会中断事务，包括发送回滚请求、事务回滚、反馈事务回滚结果、中断事务等步骤。其优点是原理简单、实现方便，但存在同步阻塞、单点问题、脑裂等痛点。

3PC:其实就是2PC的改进版，将提交事务请求阶段分成了CanCommit,PreCommit阶段，最后的DoCommit没有变化。
Paxos：是Lamport与1990提出的基于消息传递且有高度容错特性的一致性算法，其成功的解决了“拜占庭将军”问题（这个问题在区块链中也涉及）。其包括三种参与角色，分别是Proposer、Acceptor和Learner，这儿不展开介绍其基于数据归纳法的证明（个人也没打算深入研究），但一个重点的观念就是，2PC是基于所有参与者都同意的情况，而Paxos是基于读书参与者同意的情况>50%，google的chubby就是基于该算法的实现。