基础概念
刚性事务
强一致性,遵循 ACID 原则
柔性事务
最终一致性,基于 BASE 理论,允许一段时间内不一致,但最终要一致
一、2PC模式(刚性)
2 phase commit 两阶段提交,又叫做 XA Transaction,由数据库提供原生支持
- 第一阶段
事务管理器,要求涉及到该事务的数据库预提交此操作,并反馈是否可以提交 - 第二阶段
事务管理器要求每个数据库提交数据,如果有任何一个数据库否决了本次提交,所有的数据库都会进行回滚操作
- 缺点
性能比较差,不适合高并发场景
实现不完善
二、TCC(柔性)
T(try) —— C(confirm)——C(cancel)
三、最大努力通知(柔性)
主要用于和第三方进行通讯,不保证一定通知成功,但要提供可查询操作结果的接口,如果第三方通知我们失败了,我们还可以调用第三方的查询接口进行结果查询
比如下单失败回滚了,但是库存已经冻结了。此时订单服务可以给库存服务发送 MQ 消息,但是不能只发送一条,万一发送失败了库存服务就接受不到我们的通知了,所以我们要设置一个最大通知次数,每隔一段时间发送一条通知。直到库存服务告诉我们,他已经收到通知了,或是达到了最大通知次数就不再发送了。
案例: 调用支付宝进行支付,支付宝对我们的支付结果通知就是最大努力通知
四、可靠消息 + 最终一致性方案(柔性)
异步,最终达到一致
事务提交之后,发送一个消息通知其他服务,其他服务通过订阅消息异步达到最终一致性
比如下单成功之后,发送一条 MQ 消息去给用户增加购物积分
总结
如果是高并发场景推荐使用方案三、四,基于消息通知