微服务产生的背景
传统单机服务，保证ACID是很容易的，但随着业务量的提升，订单系统，财务系统，人员管理系统都需要拆分成独立的模块，单个服务器已经无法满足这么大的负载，所以每个独立的模块都需要安装在单独的服务器。
1、cap理论
当每个独立的模块都拆分过后，分布式事务的一致性就出现了问题。A用户在银行转账给B用户，A用户扣款100成功，但是B用户那边的系统宕机或者一些网络原因，导致B用户账户不变，这时候就出现了不一致性。
cap理论就此诞生，一致性，可用性和分区容错率。这三个是不能全部满足的，当满足一致性和可用性，就要牺牲分区容错率，也就是只能满足其二。
也是就出现了base理论，最终一致性就好。
2、2pc/3pc
两阶段提交的工作步骤是什么呢？
分为管理者和协调者。
当收到订单请求后
1）管理者询问各个参与者是否已经准备就绪。
2）当全部都准备就绪，则所有参与者发起commit，反之则不发起。
这种强一致性是有缺陷的，因为大家都是同步，如果有一个参与者超时或者业务处理时间过长，这时候其他参与者都会阻塞。
于是3pc就出现了。
三阶段提交主要优化了超时时间，会预处理消息，当某个参与者超时的时候不会一直阻塞。
3、TCC
TCC模式是阿里官网的模式，全程是Try confirm cancel。TCC也属于强一致性，适合与金额相关的业务。
Tcc工作步骤是什么呢?
Try阶段：
1）用户下单，把状态改为下单中
2）库存-1，冻结1个库存
3）金额-10，冻结10金额
Confirm阶段：
1）改为下单成功
2）正常减少库存
3）正常扣款-10
Cancel阶段：
1）改为下单失败
2）库存还原
3）金额还原
4、本地消息表
1）A系统本地成功写入业务表，存入消息表，发送mq。
2）B系统通过消息表主键保证幂等性，然后再存入业务表。
3）A系统通过监听B系统是否消费成功来决定是否回滚。
5、最大努力通知方案
上游在本地事务一切正常，发送mq消息给下游，重试几次，消费成功则ok，消费失败则通过手动补偿机制进入死信队列，存入表。
