分布式CAP回顾
- 一致性 Consistency： 在分布式系统中数据往往存在多个副本，一致性描述的是这些副本中的数据在内容和组织上的一致
- 可用性 Availability： 描述系统对用户的服务能力，所谓可用是指在用户能够容忍的时间范围内返回用户期望的结果
- 分区容错性 Partition Tolerance： 分布式系统通常由多个节点构成，由于网络是不可靠的，所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性，即网络分区，分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务
两阶段提交(Tow Phase Commit 2pc)
基本原理
数据库做了数据分片，需要保证同时提交事务，保证同时成功或失败，需要一个第三方来进行事务管理，也就是Transaction Manager，简称TM，另外两个或几个数据库为Resource Manager，简称RM
-
第一阶段提交：TM通知RM预提交，RM操作SQL，undo / redo写入日志，但是不会提交，然后RM们会把结果返回给TM
-
第二阶段提交：假设RM返回的结果都是成功，TM通知RM正式commit事务并释放资源，然后把提交结果返回给TM；只要其中一个失败，自然是rollback
缺点
单点故障：分布式事务依赖TM，只要它挂了，所有需要TM的分布式事务提交都不行了
同步阻塞：第一阶段到第二阶段，资源被锁
数据不一致：假设第二阶段某一RM因网络故障没有收到事务提交／回滚通知，就会一直占用资源
优化
- 超时机制
- TM：如果指定时间没有收到所有RM回应，则退出等待并发送回滚消息
- RM：如果指定时间没有收到TM二阶段消息，其实是不可以回滚的，因为如果是提交，那么数据就不一致了
- 提前询问，相当于三阶段提交
三阶段提交(Three Phase Commit 3pc)
其实就是相当于在两阶段提交之前，先发一条消息给所有RM进行询问，看是不是都可以收到正常回应，如果不可以，那后面的操作就可以不进行了。再加上超时机制，已经可以尽量减少两阶段的缺点所带来的问题了
但是，我们并不可以百分百保证，询问之后就不会刚好出问题，所以，问题还是存在的
还有就是，实际上我们很多时候都只是使用了两阶段，原因嘛，当然是效率问题；而且是使用现成的框架而不是自己实现这些两阶段三阶段的模型，比如seata、tx-lcn、tcc等，当然，也可以自己使用比如rocket mq等消息队列来实现