分布式系统一致性问题讨论
CAP理论
CAP理论表示的是分布式系统中三个重要的属性，但是也是三个互为悖论的属性。
- Consistency：一致性属性，数据的变动必须是同步强一致的
- Availability：可用性属性，在可接受的范围内正确地响应用户的请求
- Partition tolerance：分区容错性属性，即某节点或分区故障时，系统人能满足上面的属性要求
为啥是互为悖论的属性呢？
比如在单点系统中，可以很好的满足C&A，但是却很难保证P； 而在分布式系统中，为了保证P，就需要在C与A之间做出平衡，比如承受一定时间内的数据不一致。
CA no P
如何保证在分区的情况下，保证分区的容错性呢？一种较为简单的做法是将所有的数据都放在一个分布式节点上。
如单站点数据库、集群数据库是这样的设计。
CP no A
这个就是说每个操作都需要强一致性，而为了满足P则会导致同步时间的延长，这样放弃可用性的属性，当系统受到分区故障，受影响的服务需要等待，这期间服务是不可用的。
如分布式数据库就是这样设计。
AP no C
要求高可用并允许分区，则放弃一致性。一旦分区发生节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
这里说的放弃一致性，是放弃数据的强一致性，最终的数据还是要一致的。
如Web缓存、DNS系统就设计成这个样子。
BASE理论
BASE是Basically Available(基本可用）、Soft state(软状态）和Eventually consistent(最终一致性）三个短语的简写。
BASE理论的出现其实是对CAP理论中的C和A权衡的结果，其核心的思想就是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方法来使系统达到最终一致性。
基本可用
基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性的的情况，如响应时间上的下降。
软状态
软状态是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
一致性的级别
- 强一致性
- 单调一致性
- 会话一致性
- 最终一致性
- 弱一致性
分布式一致性的实现
X/Open组织定义了分布式事务处理的模型，模型包括：
- AP 应用程序
- TM 事务管理器
- RM 资源管理器
- CRM 通信资源管理器
二阶段提交 2PC
2PC是基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一套理论。
在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个全局的组件作为协调者来统一掌控所有的节点的操作结果。
因此，2PC的核心思想就是，各节点将操作结果通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
二阶段提交其实就是两个阶段：
准备阶段
事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务。
具体步骤：
- TM向所有参与者节点询问是否可以执行commit操作，并开始等待各个节点的响应
- 参与者节点执行所有事务操作
- 各参与者节点响应TM的询问，同意或不同意，这中间也可能出现超时
提交阶段
如果TM收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(必须在最后阶段释放锁资源)
下图展示了成功和失败的两种情况：
2PC的缺陷
- 同步阻塞问题：在整个过程中，所有参与者都是事务阻塞型的。在这期间，节点无法被访问
- 单点故障问题：如果TM故障，那么所有参与者将一直阻塞下去（我觉得这个可以加个超时来解决~~）
- 数据不一致问题：TM提交commit或rollback可能会出现局部性的网络异常或发送故障，导致部分成功。这样数据就存在不一致问题。
三阶段提交 3PC
3PC把2PC的准备阶段一分为二，具体阶段为：
CanCommit阶段
这个阶段就是2PC中的准备阶段，TM向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
这里与2PC不同的是，3PC的参与者在接到请求后不是马上执行，而是判定自己是否可以顺利执行事务，是的话返回Yes响应，并进入预备状态，否则反馈No（2PC是执行成功后才会返回yes）
PreCommit阶段
协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能：
1. 所有参与者及诶单都是YES反馈
- TM向参与者发送PreCommit请求，并进入Prepared阶段；
- 参与者节点接到PreCommit请求后，会执行事务操作；
- 参与者节点根据事务执行的情况，反馈信息给TM，成功就是ACK响应，同时等待最终的执行
2. 不是所有参与者及诶单都是YES反馈
假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
- TM向所有参与者发送abort请求
- 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。
doCommit阶段
针对上面的2种情况，doCommit阶段也会有2种情况
执行提交
- TM向所有参与者发送doCommit请求，从预提交状态进入到提交状态
- 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
- 事务提交完之后，向TM发送Ack响应。
- TM接收到所有参与者的ack响应之后，完成事务。
回滚事务
- TM向所有参与者发送abort请求
- 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
- 参与者完成事务回滚之后，向TM发送ACK消息
- TM接收到参与者反馈的ACK消息之后，执行事务的中断
2PC VS 3PC
引入超时机制，在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。
2PC和3PC都没有很好的解决资源阻塞的问题，以及彻底解决分布式不一致的问题，3PC可能要稍微好一些，但是还是会出现不一致的情况。