在聊分布式一致性问题前，我们先来谈谈什么是CAP理论。
在分布式系统环境下，由于存在硬件、网络的隔离，对于一些事务操作不像单机环境下那样简单，于是出现了CAP理论。它的定义如下：
- Consistency（一致性）
由于分布式环境存在多个节点，这些节点上的数据在同一时间所存储的数据必须是一致的，这就是一致性协议。在并发环境下一个客户端从任何一个节点获取的数据如何保证是最新的。对于服务端来说，需要保证在整个分布式环境下的数据复制问题。
- Availability（可用性）
可用性很好理解，任何时刻需要保证服务的可用和稳定。
- Partition Tolerance（分区容错）
所谓分区容错是指某个时刻出现网络或者硬件不可用，甚至宕机，其它的机器还能保证正常可用。
大部分情况下我们能够很好的保证可用性和分区容错，但是对于一致性问题一直很难保证。业界对于解决一致性问题常用的法则有三种：
二阶段提交（2PC）
1、提交阶段
协调者向参与者发起事务命令，参与者接收到事务命令进行本地事务的undo或redo操作，但不进行事务提交，将执行结果反馈给协调者，大致流程如下：
2、执行阶段
通过在提交阶段接收到参与者的反馈，做出相应的动作。如果全部是成功，则向参与者发送指令进行事务的提交，否则只要有一个失败，则进行事务的回滚。
二阶段提交带来的问题：
- 参与者与协调者的交互流程为阻塞性，意味着这期间其它的一些请求处理被阻塞了
- 协调者出现故障时，所有事务都处于待提交状态，无法恢复
- 无法解决数据不一致问题，当第二阶段进行事务的提交过程中，如果任何一个节点出现不可用，协调者无法感知到
通过以上三种缺点带来了另外一种解决方案：三阶段提交(3PC)
三阶段提交（3PC）
三阶段提交相比于两阶段提交优化了第一部分，加入了请求询问及执行响应结果的ack。
1、canCommit
协调者首先询问参与者是否可以进行事务命令，参与者应答协调者yes或no
2、preCommit
这时候有两种情况：
- 当所有参与者返回yes应答，则发送preCommit指令进行事务的本地预提交，当每个参与者事务进行完毕，给协调者进行反馈ack。
- 只要任何一个参与者在第一个确认简单返回了no，本次事务中断，或者任何事务预提交提交阶段超时或无反馈，本次事务中断。
3、doCommit
当前面两个阶段执行完毕，协调者收到了每一个参与者应答ack，则进行doCommit命令，真正的事务提交，当所有的事务都已提交则返回haveCommitAck，以便协调者知道事务是否真正提交，下面梳理了整个流程笔记：
3PC相比于2PC，解决了超时及每个阶段节点的状态反馈，但是也无法解决另外一个问题，当在预提交阶段，进行事务回撤处理时，某个节点由于网络原因未收到请求，则带了数据的不一致性，所以针对这个问题，有一种算法(Paxos)解决了此问题，例如zookeeper就是采用这种算法，至于zookeeper的一些实现细节，我们找时间在进行分享。
敬请持续关注“聊点源码”微信公众账号！
【长按下方微信，获取更多资讯】
你还在等什么？