这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天
上篇中的理论主要针对CA类型和AP类型的系统，本文针对CP系统进行进一步探讨。- 注：CA型系统：单机存储系统，完全抛弃分区的概念；AP型系统：注重用户体验的系统，只保证分布式数据的最终一致性；CP型系统：数据一致性需要保证强一致的系统往往和金融相关的比较关键的业务上使用。
分布式事务
事务是数据库系统中的重要概念，指的是将多个数据库操作强制绑定为同一个操作（ACID中的原子性），从而保证数据库中数据的一致性。分布式事务即在分布式系统的基础上实现事务，相比单机数据库，分布式事务需要考虑网络通信导致的网络问题，因此较为复杂，在实际的项目中，一般都会避免使用分布式事务，降低项目的复杂度。
两阶段提交
-概念引入
- Coordinator: 协调者，作用保存各分布式节点的当前的状态并协同同一组Participants的事务操作。
- Participant：参与者通常为一组向Coordinator报告状态。
- Prepare阶段：
- Coordinator向Participants发送Prepare请求。
- Participant接收请求完成Prepare后，向Coordinator发送Done消息。
- Commit阶段：
- Coordinator向Participant发送Commit命令。
- Participant接收到Commit命令后完成事务的提交，返回给Coordinator ACK信息。
- 系统可能出现的问题：
- 实际上但凡是需要通信的阶段都有可能出错，这里主要考虑宕机的问题。
- 参与者宕机，协调者不宕机：准备阶段宕机的参与者没有回传Done信息，超时后执行事务的回滚操作。
- 协调者宕机，参与者不宕机：需要有特殊的机制启用新的协调者，然后通过查询原来的状态选择完全重新开始准备阶段还是直接开始提交阶段。
- 全部宕机：出现未决的状态，需要数据库管理员来处理冲突。
- 实际上但凡是需要通信的阶段都有可能出错，这里主要考虑宕机的问题。
- 两阶段提交本身的缺陷：
- 性能问题： 协调者与参与者间需要多次通信，有一定的带宽压力。
- 协调者单点故障：协调者的存在是唯一的，可能出现旧的协调者宕机但是新的协调者却无法上线的中间状态，导致服务全部暂停，产生阻塞。
- 分区没有保证数据的强一致：可以设想在某些场景下，部分参与者完成事务的提交后即可关注到数据的改变而其他提交失败的节点看到的数据是旧的，这给业务带来一种摇摆的不确定性，当然可以通过限制参与者的提交全部完成后才能观测到新的数据，但是这损失了系统的可用性。
三阶段提交
三阶段提交将两阶段提交的准备阶段拆为CanCommit和PreCommit两部分，类似TCP的三次握手，第一次握手只是为了试探服务是否可以，三阶段提交解决了单点故障和阻塞的问题，但是网络性能和网络分区导致的数据不一致仍然没有得到有效的解决。
