智能手机的出现，使互联网发生了巨大的改变。想想10年之前，互联网的入口恐怕95%以上都是电脑Web网页。而如今，我们可以通过电脑、手机APP、微信小程序、平板电脑、智能电视等不同的方式访问一个网站。更是有些网站搞什么秒杀、双十一什么活动，更使传统的单机/集群服务器早就不堪重负，所以分布式系统在这之后得到迅速的发展。
分布式系统会带来各种各样的问题，像普遍的节点故障、不可靠的网络、异构的硬件。本文主要介绍一下分布式系统中为保证数据一致性产生的几个一致性协议。
一、分布式一致性问题
在分布式系统中，各中心下有不同的数据库，同一业务可能造成跨库操作。即使不跨中心，但可能某一中心下数据库进行了分库分表，同一中心下的业务也可能会进行跨库、跨表操作。每个节点都明确知道自己事务操作的结果，但无法直接获取其他分布式节点的操作结果。此时就产生了分布式一致性问题。
这是多中心的一个业务，跨数据库处理，每个节点都知道自己的事务执行情况，但却不能直接获取其他中心的事务情况。
如果客户中心数据过多进行分库分表处理，并进行了异地部署，就会下面这种情况。
为了保证事务的ACID特性，就需要引入一个称为“协调者（Coordinator）”的组件来同一调节所有分布式节点的执行逻辑，这些被调节的分布式节点被称为“参与者（Participant）”。
基于这种思想便衍生二阶段提交和三阶段提交两种协议。
二、2PC
2PC（Two-Phase Commit）即二阶段提交，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。
概念
通常，二阶段提交也被称为是一种协议（Protocol）。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点（称作参与者）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交（比如将更新后的数据写入磁盘等等）。
二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
成立的前提
1.节点中一个协调者，其他为参与者，并且节点之间可以互相通信
2.节点采用预写式日志，且日志被写入后可以保存在可靠的储存设备上，节点损坏不会导致日志消失
3.节点不会永久性损坏，损坏后可以修复
算法描述
阶段一：提交事务请求，只要是询问各节点事务是否可以提交。
阶段二：执行事务提交或回滚
优缺点
优点：
原理简单，实现方便
缺点：
同步阻塞：所有的参与者在这个过程中的都会等待其他参与者相应的过程，等待过程无法执行其他操作。
单点问题：协调者就一个，一旦挂了，这套操作就当场爆炸了。
数据不一致：发送提交命令时，协调者崩溃或其他网络异常使只有部分参与者执行了提交命令，会产生数据不一致性。
太过保守：任何参与者出现问题都需要协调者通过超时机制来判断是否中断事务，没有完善的容错机制，任何一个节点失败都会导致整个事务失败。
关于网络中断：2pc所有的网络超时都会造成事务中断
三、3PC
3PC（Three-Phase Commit）即三阶段提交，与二阶段提交最大的不同是“非阻塞”协议。
概念
三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段，使得原先在两阶段提交中，参与者在投票之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
算法描述
三阶段提交将二阶段提交的第一阶段一分为二，先是询问能否提交，然后进入提交准备阶段，第一阶段不需要进入阻塞状态。
阶段一：CanCommit
如果参与者自身认为可以顺利执行事务会反馈Yes响应。
阶段二：PreCommit
第二阶段根据阶段的返回进行事务预提交或者中断事务
上面是事务顺利进行的操作，如果是中断就会进行下面的操作。
阶段三：doCommit
第三阶段就是真正的事务提交….当然了，也可能是回滚
先说执行提交的情况，正常处理
如果第二阶段有参与者返回了No的信息，那这里就需要回滚处理。
优缺点
优点：降低了参与者的阻塞范围，从第二阶段才开始进行阻塞，并且出现单点故障后继续达成一致。
缺点：第三阶段出现协调者出现问题或网络异常，参与者仍会进行提交，这样必然导致不一致问题。
网络中断：3PC第三阶段的网络超时会继续提交，其他阶段是网络终断。
四、总结
这里只是提了一下2PC和3PC的主要思路，具体实现远比这复杂的多，有些时候想想，人类的脑袋真是可怕，这都是怎么想到的呀！！！
多读读看看，希望学会更多的知识！
参考资料：