两阶段提交
流程描述：
总共有两个角色，协调者，参与者，协调者只有一个，参与者可以多个
1.准备阶段：
协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写redo或者undo日志,然后锁定资源，执行操作，但是并不提交
2.提交阶段：
如果每个参与者都明确返回准备成功，也就是预留资源和执行操作成功，则协调者向参与者发起提交指令，参与者提交资源变更事务，释放锁定的资源。如果任何一个参与者明确
返回准备失败，这协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源
存在的问题:
1.阻塞：所有的过程都是同步进行的，如果没有收到响应，则会一直处于阻塞状态
2.单点故障：如果协调者宕机，参与者没有协调者指挥，则会一直处于阻塞状态，
3.脑裂：协调者发送提交指令，有的参与者接收到并执行了事务，有的没有接收就没有执行，多个参与者之间不一致
三阶段提交
三阶段提交在两阶段的基础上增加超时机制来解决阻塞的问题
流程描述：
1.询问阶段：
协调者询问参与者是否可用完成指令，参与者只需要回答是或不是，不执行惭怍，这个阶段超时的话会导致中止
2.准备阶段：如果在询问阶段所有参与者都返回是，则协调者向参与者发送预执行操作，然后参与者写redo和undo日志，执行操作还是不提交，如果在询问阶段任意参与者返回不是，则协调者向参与者发起中止请求
3.提交阶段：如果每个参与者都在准备阶段返回准备成功，则协调者向参与者发起提交指令，参与者提交资源变更事务，释放锁定的资源，如果任何参与者返回准备失败，则协调者发起中止指令，参与者取消已经变更的事务，执行undo日志
和两阶段提交对比的优点：
1.增加了一个询问阶段，能够尽早的发现无法执行的操作而进行中止，减少这种情况的发起，避免无谓的操作
2.在准备阶段以后，协调者和参与者执行任务都增加了超时机制，一旦超时，则协调者和参与者都会继续提交事务，默认为成功，这是根据概率统计超时后默认为成功的正确性是最大决定的。
TCC提交(try-confirm-cancel)
在高并发的系统中，两阶段和三阶段用的很少，因为在极端情况下，系统会产生阻塞或者不一致的情况，并且实现复杂度高，性能低
TCC协议把一个任务拆分成Try,confirm,cancel三个步骤，正常的流程会执行try,如果执行没有问题，则再执行confirm,如果执行过程中出现问题，则执行操作的逆操作cancel。如果执行逆操作，tcc具有一定的自我修复能力,逻辑上也是一种简化版的三阶段提交
此外还有其他一些模式可以实现最终一致性：
1.查询模式：根据返回的不同状态来做不同的处理，依赖流水号的唯一标识
2.补偿模式：可以分为自动恢复，运营人员手工补偿，通过技术手段来补偿
3.异步确保模式:如电商中的物流配送等
4.定期校对模式
5.可靠消息模式:需要保证消息的可靠发送，以及消息的幂等性
缓存一致性模式
