zookeeper学习（三）

      在上一篇中，我们介绍了为什么使用分布式，为什么会出现分布式数据一致性问题，以及相关分布式理论：CAP/BASE理论，这些是我们进行后边介绍的分布式一致性算法的基础，正是由于在系统的可用性和数据一致性之间反复的权衡，于是出现了一系列的一致性协议，如2PC，3PC，paxos算法等。本篇就介绍两个最常见的分布式一致性算法：两阶段提交（2PC），三阶段提交（3PC）以及它们的相关应用。

其实我觉得这些分布式一致性算法其实应该叫分布式共识（distributed consensus）算法，不同的一致性上下文含义不同。共识系统则很清晰， 就是多个参与者针对某一个议题达成一致意见，如经典的具有高度容错的基于消息传递的paxos算法，而2pc，3pc无法容错，太过保守。而不是针对使副本数据都一致。这是我的一点看法，其实我看这个的概念的时候也很迷糊，到现在还是在头脑中争议很大，但我觉得，对于这些概念的理解应该放在固定的业务场景中，看在业务中解决了什么问题，而不是转牛角尖非要把这些算法分门别类。

       另外，我自己的理解，这些分布式一致性算法的目的并不是达到了副本数据的强一致性，因为CAP理论告诉我们，这是不可能的，而是在可用性和一致性的均衡处理上，用这些算法可以达到BASE状态，确保我们的分布式系统正确运行，那些数据副本的同步问题并不是一致性算法所要解决的，因为副本的同步不管是Mysql主从同步，还是其他master-slave集群的同步都是异步的，所以不可能达到强一致性，所以这些一致性算法是用来保证分布式系统的可用--一致的算法。例如，我们可以将paxos算法看做是分布式共识算法，它的目的就是怎么样对某个值（决议）在集群中达成一致，所以这可以用于集群中的leader选举，写数据过程。而2pc，3pc就是解决分布式事务（参与事务的事务管理器，参与者位于不同的节点）的原子性，一致性问题，而且这些算法并不是只能单一的应用于某个问题上，有很多问题都可以转化为用这些算法解决。

• 2PC、3PC的基本概念

        2PC,3PC主要是基于分布式事务的分布式一致性算法（因为分布式事务也可能会导致数据的不一致问题，这跟副本的不一致性从大类上看是都归于数据的不一致）。
在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲，两台机器理论上无法达到一致的状态。如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要不全部都执行，要么全部的都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。使用2PC,3PC可以实现分布式的强一致性和分布式事务（广义-狭义？？）。
分布式事务的概念：
通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。 所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库（可以是不同的应用对应的数据库，也可以是副本？？）。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 一般情况下，某一数据库无法知道其它数据库在做什么。因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。
二阶提交协议和三阶提交协议就是根据这一思想衍生出来的。可以说二阶段提交其实就是实现XA分布式事务的关键(确切地说：两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做)

我的理解：其实我们也可以将2PC,3PC算法看做是和paxos一样的用来对某个决议达成共识的算法，这里的决议就是是否要提交这个事务从而更新数据。但是2PC，3PC存在很多问题，比如太过保守、单点问题，所以才会产生具有高度容错性的paxos算法。

• 2PC

二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。2PC就是用来解决分布式事务的原子性问题。所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。其过程为：

第一阶段：准备阶段

事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，然后向协调者反馈YES,NO。
其具体过程：
协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
第二阶段：提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)。
注意：在2PC中，当等待超时，会进行回滚操作。

提交阶段可以分两种情况进行讨论：
执行事务提交

当协调者节点从所有参与者节点获得的相应消息都为”同意”时:
协调者节点向所有参与者节点发出”正式提交(commit)”的请求。
参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
参与者节点向协调者节点发送”完成”消息。
协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。
如下图所示：

中断事务

如果任一参与者节点在第一阶段返回的响应消息为”中止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。
参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
参与者节点向协调者节点发送”回滚完成”消息。
协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。
如下图所示：

不管最后结果如何，第二阶段都会结束当前事务。二阶段提交确实能够提供原子性的操作。

2PC的优缺点
优点：2PC的优点是很显然的，原理简单，实现方便。目前，绝大多数关系型数据库都是采用两阶段提交协议来完成分布式事务处理的。（也就是上边的2pc过程应用于关系型数据库的分布式事务）

缺点：2PC的缺点也很致命：同步阻塞，单点问题，数据不一致，太过保守
1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态，各个参与者在等待协调者发出提交或中断请求时，会一直阻塞，而协调者的发出时间要依赖于所有参与者的响应时间，如果协调者宕机了（单点），那么他就一直阻塞在这，而且无法达成一致（3PC引入了超时提交解决）。
2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3、数据不一致。出现分区，或者网络故障。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
4、太过保守：2pc没有设计相应的容错机制，当任意一个参与者节点宕机，那么协调者超时没收到响应，就会导致整个事务回滚失败。
5、二阶段无法解决的问题：协调者（在第二阶段）发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
由于二阶段提交存在着诸如同步阻塞、单点问题、脑裂等缺陷，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。

• 3PC

3PC，即三阶段提交，是2阶段提交的改进版，其将二阶段提交协议的“准备阶段”一份为二，形成了cancommit，precommit，do commit三个阶段。

与两阶段提交不同的是，三阶段提交有两个改动点。

1、引入超时机制。（超时提交策略，当第三阶段参与者等待协调者超时后会提交事务，解决参与者同步阻塞问题，同时能在发生单点故障时，继续达成一致）
2、在第一阶段和第二阶段中插入一个准备阶段。（也是为了减少同步阻塞的发生范围）

CanCommit阶段
3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
PreCommit阶段
协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。
1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
1.发送中断请求 协调者向所有参与者发送abort请求。
2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。
doCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况。

执行提交

1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。

2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

3.响应反馈 事务提交完之后，向协调者发送Ack响应。

4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。

中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。

1.发送中断请求 协调者向所有参与者发送abort请求

2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息

4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

注意：
在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。
引入超时提交的依据：
其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。

3PC解决的问题：
一旦进入阶段三：可能会出现：1 协调者出现问题（单点）    2 协调者参与者之间的网络出现故障

二阶段无法解决的问题：协调者（在第二阶段）发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit（所以产生新的协调者之后，可以确定事务的状态，这就解决了单点）。而不会一直持有事务资源并处于阻塞状态。

3PC无法解决：数据不一致以及太过保守问题。

但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

2PC,3PC的应用
我们前面说过，对于大多数的关系型数据库来说，解决分布式事务的方法就是利用两阶段提交2pc，其过程就是我们上边介绍的2PC的过程。可参考：Mysql的2pc应用 。主要涉及mysql的几个日志：mysql日志文件 ，另外还有在事务过程中的redo_log undo redo undo。

MySQL的主从同步复制原理
      我们注意，一般的主从同步并不涉及相关的分布式协议，基本都是异步使用日志或镜像进行主从同步，达成最终一致性。比如：DHFS的namenode，redis的主从同步以及MySQL的主从同步。不要把2pc，3pc，paxos等分布式一致性算法想象为处理主从复制这个过程的算法。

复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更 新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服 务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
  MySQL复制技术有以下一些特点：
         (1)    数据分布 (Data distribution )
         (2)    负载平衡(load balancing)
         (3)    备份(Backups) 
         (4)    高可用性和容错行 High availability and failover 
 整体上来说，复制有3个步骤：   

       (1)    master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
       (2)    slave将master的binary log events拷贝到它的中继日志(relay log)；
       (3)    slave重做中继日志中的事件，将改变反映它自己的数据。

第一步和后边的步骤是一个异步的过程。

      该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前，master在二日志记录这些改变。MySQL将事务串行的写入二进制日 志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master通知存储引擎提交事务。
       下一步就是slave将master的binary log拷贝到它自己的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中 继日志。
       SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数 据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。
        此外，在master中也有一个工作线程：和其它MySQL的连接一样，slave在master中打开一个连接也会使得master开始一个线程。复制 过程有一个很重要的限制——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。

了解了2PC和3PC之后，我们可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。Google Chubby的作者Mike Burrows说过，世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。后面的文章会介绍这个公认为难于理解但是行之有效的Paxos算法。