zookeeper先验知识（2PC+paxos）

一、2PC两阶段提交：

　　在分布式事务中，每个机器节点只能够明确知道自己事务操作的结果，是成功还是失败，而无法获取其他分布式节点的操作结果，因此在事务操作需要跨多个分布式节点时，需要引入一个协调者统一调度所有节点的执行逻辑。

阶段一：提交事务请求

（1）事务询问。协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

（2）执行事务。各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。

（3）各参与者向协调者反馈事务询问的响应。如果参与者成功执行了事务操作，那么久反馈给协调者yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么久反馈给协调者No响应，表示事务不可以执行。

阶段二：执行事务提交

　　在阶段二中，协调者会根据各参与者的反馈情况，来决定最终是否可以进行事务提交操作，正常情况下，包含以下两种可能。

（1）执行事务提交：假如协调者从所有的参与者获得的反馈都是yes响应，那么就会执行事务提交。

a、发送提交请求。协调者向所有参与者节点发出Commit请求。

b、事务提交。参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。

c、反馈事务提交结果。参与者在完成事务提交之后，向协调者发送Ack消息。

d、完成事务。协调者接收到所有参与者反馈的Ack消息后，完成事务。

（2）中断事务：假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，就会中断事务

a、发送回滚请求。协调者向所有参与者节点发出Rollback请求

b、事务回滚：参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源

c、反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送Ack消息

d、中断事务：协调者接收到所有参与者反馈的Ack消息后，完成事务中断

　　二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此也可以将二阶段提交看作一个强一致性的算法，下图分别展示了二阶段提交过程中事务提交和事务中断两种场景下的交互流程：

2、两阶段提交的优缺点。

优点：原理简单，实现方便。

缺点：同步阻塞、单点问题、脑裂、太过保守。

二、paxos

　　paxos算法解决的问题是，如何在一个可能发生宕机或者网络异常的分布式系统中，快速且正确的在集群内部对某个数据的值达成一致。

问题：假设有一组可以提出提案的进程集合，对于一致性的算法需要满足：被提出的提案只能有一个题案产生；假设一个提案被选定后，进程可以获取被选定的提案信息。

组成：Acceptor、Proposer、Leaner。

（1）生成提案

a、Proposer选择一个新的提案编号Mn，然后向某个Acceptor集合的成员发出请求，要求该集合中的Acceptor做出如下回应。

　　向Proposer承诺，保证不再批准比任何编号小于Mn的提案。

　　如果Acceptor已经批准过任何提案，那么其就向Proposer反馈当前该Acceptor已经批准的编号小于，但为最大编号的那个提案值。

我们将该请求成为编号为Mn的提案的prepare请求。

b、如果Proposer收到了来自半数以上的Acceptor的响应结果，那么它就可以产生编号为Mn，值为Vn的提案，这里的Vn是所有响应中编号最大的提案的Value值。

　  如果半数以上的Acceptor没有批准过任何提案，即响应中不包含任何的提案，那么此时Vn的值可以由Proposer任意指定。

（2）批准提案

　　一个Acceptor可能收到来自Proposer的两种请求，分别是prepare请求和Accept请求，对这两类请求的响应条件如下：

　　prepare请求：Acceptor可以在任何时候响应一个prepare请求。

　　Accept请求：在不违背Accept现有承诺的前提下，可以任意响应Accept请求。

　　总之，一个acceptor只要尚未响应过任何编号大于Mn的prepare请求，那么它就可以接受这个编号为Mn的提议。

参考博客：https://blog.csdn.net/qq_40378034/article/details/99681137

https://www.cnblogs.com/Leo_wl/p/6002110.html