分布式事务
1.TCC补偿性事务
TCC提供了一个编程框架,将整个业务逻辑分为三块:Try、Confirm和Cancel三个操作。以支付场景为例,一次支付涉及mysql和oracle的金额变化。
Try阶段:分别冻结mysql和oracle中的金额。
Confirm阶段:分别扣除Try阶段中冻结的金额。
Cancel阶段:分别将冻结金额解冻恢复到用户的余额中。
由于可能会出现多次提交,需要支持幂等,即同一次请求必须只能成功一次,且每次返回结果都一样。TCC对代码侵入性强,不同的业务场景所写的代码都不一样,复杂度也不一样,代码也不能很好的复用。
2.消息队列+最终一致性(最大努力型)
去哪儿、支付宝也采用过这种方式实现最终一致性。
利用消息队列+本地事务。如上例,一次支付涉及mysql和oracle的金额变化。
2.1 执行mysql的本地事务
2.2 发送消息(消息队列来保证消息发送成功后就不会丢)
2.1、2.2执行失败就回滚本地事务。当然发送消息成功后如oracle的操作执行失败呢?设置最大重试次数,直到消息的数据处理完成。
思路就是将分布式事务拆分成多个本地事务,分别来保证每个事务的完整。
本地事务
不用事务的编程框架来管理事务,直接使用资源管理器来控制事务。典型的就是java.sql.Connection 中的setAutoCommit、commit、rollback方法。
本地事务的优点
支持严格的ACID属性
可靠
高效
状态可以只在资源管理器中维护
应用编程模型简单
本地事务的局限
不具备分布式事务处理能力
隔离的最小单位由资源管理器决定,如数据库中的一条记录
本地事务比较简单,对事务不太了解的同学可以阅读我的博客中其他关于事务的内容。