微服务下如何保证事务一致性

1、微服务产生的背景

传统单机服务，保证ACID是很容易的，但随着业务量的提升，订单系统，财务系统，人员管理系统都需要拆分成独立的模块，单个服务器已经无法满足这么大的负载，所以每个独立的模块都需要安装在单独的服务器。

1. cap理论

当每个独立的模块都拆分过后，分布式事务的一致性就出现了问题。A用户在银行转账给B用户，A用户扣款100成功，但是B用户那边的系统宕机或者一些网络原因，导致B用户账户不变，这时候就出现了不一致性。

cap理论就此诞生，一致性，可用性和分区容错率。这三个是不能全部满足的，当满足一致性和可用性，就要牺牲分区容错率，也就是只能满足其二。

也是就出现了base理论，最终一致性就好。

3、2pc/3pc

两阶段提交的工作步骤是什么呢？

分为管理者和协调者。

当收到订单请求后

1）管理者询问各个参与者是否已经准备就绪。

2）当全部都准备就绪，则所有参与者发起commit，反之则不发起。

这种强一致性是有缺陷的，因为大家都是同步，如果有一个参与者超时或者业务处理时间过长，这时候其他参与者都会阻塞。

于是3pc就出现了。

三阶段提交主要优化了超时时间，会预处理消息，当某个参与者超时的时候不会一直阻塞。

4、TCC

TCC模式是阿里官网的模式，全程是Try confirm cancel。TCC也属于强一致性，适合与金额相关的业务。

Tcc工作步骤是什么呢?

Try阶段：

1. 用户下单，把状态改为下单中
2. 库存-1，冻结1个库存
3. 金额-10，冻结10金额

Confirm阶段：

1. 改为下单成功
2. 正常减少库存
3. 正常扣款-10

Cancel阶段：

1）改为下单失败

2）库存还原

3）金额还原

1. 本地消息表

1）A系统本地成功写入业务表，存入消息表，发送mq。

2）B系统通过消息表主键保证幂等性，然后再存入业务表。

3）A系统通过监听B系统是否消费成功来决定是否回滚。

1. 最大努力通知方案

上游在本地事务一切正常，发送mq消息给下游，重试几次，消费成功则ok，消费失败则通过手动补偿机制进入死信队列，存入表。