分布式事务_dbproxy 自动带上事务-优快云博客

1、基于XA协议的两阶段提交方案

交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。
第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。

两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

2、TCC方案

TCC方案在电商、金融领域落地较多。TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。基本原理如下图所示。

事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用confirm接口或者cancel接口。如果接口调用失败，会进行重试。

TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。当然TCC方案也有不足之处，集中表现在以下两个方面：

上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大

3、基于消息的最终一致性方案

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。

消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。

公司	实现方案
阿里	基于TCC模型实现分布式事务 1、阿里GTShttps://help.aliyun.com/product/48444.html?spm=5176.8135549.918380.btn5.14866ddc6gk1Ah 2、阿里GTS微博：https://weibo.com/jiangyu666?spm=a2c4e.11153940.blogcont542020.23.589066baBOOm1n&is_all=1
百度	目前，百度自己开发的分布式数据库已经开始支持分布式事务，并在支付业务中试用。同时百度开发的dbproxy也开始支持分布式事务，并在部分业务中开始使用。

公司

实现方案

阿里

基于TCC模型实现分布式事务

百度

目前，百度自己开发的分布式数据库已经开始支持分布式事务，并在支付业务中试用。同时百度开发的dbproxy也开始支持分布式事务，并在部分业务中开始使用。

主要开源框架：

框架名称	嵌套调用	RPC框架支持	事务日志存储方式	git地址	star数量
tcc-transaction	不支持	不耦合RPC框架，使用doubbo,thrift,web service,http等都可	DB、redis、zk、file	https://github.com/changmingxie/tcc-transaction	2446
Hmily	不支持	dubbo、motan、springcloud，提供：dubbo相关demo	redis、mongodb、zk，file，DB	https://github.com/yu199195/hmily	1381
ByteTCC	不支持	dubbo、springcloud	file	https://github.com/liuyangming/ByteTCC	1300
EasyTransaction	支持	Dubbo、SpringCloud	DB、Redis	https://github.com/liuyangming/ByteTCC	904