分布式环境的各种问题：
- 通信异常： 分布式节点之间的通信
- 网络分区： 脑裂，分布式节点中一部分节点失去了通信。
- 节点故障： 某个节点发生宕机现象
- 三态： 超时、成功、失败
acid & cap & base ---理论
单机事务acid
acid： 事务的四种特性， 原子性、一致性、隔离性、持久性
隔离性： sql事务隔离级别，读未提交（另外一个事务操作的值都可以取到）、读已提交、可重复读（幻读）、串行化
分布式事务 cap理论
一致性
可用性
分区容错性
base理论
基本可用、弱状态、最终一致性
分布式一致性协议
两阶段提交协议
协议主要分为两个角色： 协调者、参与者
两个阶段： 投票阶段 - 提交阶段 或者 投票阶段-中断阶段
经常应用于关系型数据库的分布式一致性场景
投票阶段
1. 协调者向参与者发送执行事务的请求
2. 参与者开始执行事务，并记录相关日志，可回退。
3. 参与者向协调者反馈执行结果
提交阶段 或者中断阶段
如果所有的事务执行结果都是成功的则：
1. 向参与者发送commit命令
2. 参与者执行commit，并释放资源
3. 向协调者反馈执行结果
4. 协调者收到ack之后，事务完成。
如果有未执行成功的参与者，则：
1. 发送事务回滚命令
2. 各个参与者回滚
3.反馈事务回滚结果
4. 完成事务中断
两阶段提交的缺点：
- 整个流程有同步阻塞的问题，各个节点在等待协调者反馈结果过程中，一直占有资源
- 协调者的角色很重要，一旦异常则整个流程崩塌。 （单点问题）
- （数据不一致问题），发送commit之后如果协调者没有收到commit请求，则会出现数据不一致的情况。
三阶段提交协议
为了解决上面的问题提出了三阶段提交：
canCommit -> preCommit -> commit
canCommit
1. 协调者向参与者发送canCommit命令
2. 参与者根据自身情况，分析是否可提交，并不提交commit
3. 向协调者返回结果yes
preCommit
1. 若返回的canCommit都为yes，则发送preCommit
2. 协调者收到preCommit之后提交，开始执行事务。
3. 将结果返回协调者
commit
1. 若返回成功，则发送commit命令
2. 各个协调者执行commit命令
3. 返回commit结果
4. 是否中断，完成执行 --如果协调者故障，超时自动提交
为什么要有三阶段提交： 降低了参与者的阻塞范围
ps: 个人体会不到三阶段比二阶段提交好在哪里。。
