m0_51697147的博客

CAP定理告诉我们，一个分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个基本需求，最多只能同时满足其中的两个。一致性和可用性永远无法存在一个两全其美的方案，只能尽可能地适用于某种情形。

保证数据的一致性有两种情况，一种是重新选取出新leader后的数据同步，还有一种是leader处理完事务请求后与follow保持数据一致。

首先zookeeper的核心是原子广播，这个机制保证了各个server之间的同步，而实现这个机制的协议叫做ZAB协议。ZAB协议是为zookeeper专门设计的一种支持故障恢复的消息广播协议。ZAB协议只允许有一个主进程接收客户事务请求并处理，也就是Leader。当Leader收到请求后，将请求事务转化为事务Proposal。由于leader会为每一个follow创建一个队列，所以会将该事务放入响应队列中，按顺序来处理事务，保证事务的顺序性。之后leader会在队列中顺序向其他节点广播该提案，follow

在ZAB协议中，每个事务都有一个编号ZXID，ZXID由两部分组成，高32位是epoch，低32位为递增计数器。 epoch：选举周期，也就是每换一次Leader，epoch的值加一； 计数器：随事务的到来每次加一，每当换一次Leader，计数器会清零，从零开始加；myid：当我们搭建zookeeper的集群时，我们需要手动创建一个myid的文件，这个文件里面我们随便写入一个数字，但zk集群里面每个节点的数字都不能相同，在Leader的选举时会用到ZXID和myid。

Leader选举是保证分布式数据一致性的关键所在，Leader的选举发生的情况有两种：一种是服务器启动时选举，另一种是运行期间Leader宕掉或与Leader保持连接的机器少于一半，这时会进行重新选Leader。

paxos算法是一种基于消息传递且具有高度容错性的一致性算法，解决的问题是一个分布式系统如何就某个值或者某个协议达成一致，该算法的前提是假设不存在拜占庭将军问题。在该算法中一共有三种角色：proposer、acceptor和learner。proposer负责提出提案，acceptor负责对该提案做出裁决，learner负责学习得到的提案。为了避免单点故障，会有一个acceptor集合，proposer向该集合发送提案，acceptor集合中的每一个成员都有可能同意该提案并且每个acceptor只能批准

2PC可以保证数据库中redo log和binlog两个日志的一致性，要么都成功，要么都失败。

2PC：网络原因造成一部分参与者收到消息，一部分参与者没有收到消息。3PC：参与者接收到preCommit消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，这种情况下该参与者依然会进行事务的提交，这必然出现数据不一致的情况。

1.3PC比2PC多了一个cancommit阶段，减少了不必要的资源浪费。2.3PC引入超时机制，同时在协调者和参与者中都引入超时机制。

二阶段提交会统一决定事务的提交或回滚，从而能够有效地保证分布式数据一致性。二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此也可以将二阶段提交看作一个强一致性的算法。

Zookeeper为分布式应用提供了一个高效可靠的分布式协调服务。它的实现是依赖于ZAB协议，实现了一种主备模式的架构来保持集群中数据的一致性。Zookeeper使得分布式应用可以通过一个共享的树形结构的命名空间实现协调。

每个server保存一份数据副本，就是每个server都会有自己的一份数据副本，每个数据副本的内容都是统一的，在更改数据副本时，超过一半的server成功更改后，就认为是更改成功了。实时性，在一定范围内，client能读到最新数据。为什么是一定范围内呢？因为这里涉及到过半提交的策略，超过一半的server更新成功Leader就认为更新成功。（Paxos算法）

1.ZNode：每个节点在Zookeeper中叫ZNode，并且有唯一的路径标识，是ZooKeeper中数据的最小单位，每个ZNode上都可以保存数据以及创建子节点，但临时节点不能创建子节点。2.ZNode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本。

Zookeeper更适合以查询（非事务）为主的操作，不适合以写（事务）为主的操作，因为只有一个Leader，但有多个Follow。