分布式事务--TCC的中间件--选型/对比

素颜马尾好姑娘i 2023-10-01 18:28 16阅读 0赞

原文网址：[分布式事务--TCC的中间件--选型/对比\_IT利刃出鞘的博客-CSDN博客][--TCC_--_IT_-CSDN]

## **简介** ##

**说明**

本文介绍分布式事务的TCC的一些中间件。包括：Seata，**TCC-transaction、**ByteTCC、Himly、EasyTransaction、LCN

**为什么要使用TCC中间件**

感知各个阶段的执行情况以及推进执行下一个阶段的这些事情，不太可能自己手写实现，太复杂了。

## **中间件介绍** ##

<table> 
 <tbody> 
 <tr> 
 <td> 中间件名称 </td> 
 <td> Github地址 </td> 
 <td> star数量 </td> 
 <td> 简介 </td> 
 </tr> 
 <tr> 
 <td> Seata </td> 
 <td> <a href="https://github.com/seata/seata" title="https://github.com/seata/seata" rel="nofollow">https://github.com/seata/seata</a> </td> 
 <td> 18.3K </td> 
 <td> 阿里。TCC模式仅支持dubbo，不支持feign。 </td> 
 </tr> 
 <tr> 
 <td> tcc-transaction </td> 
 <td> <a href="https://github.com/changmingxie/tcc-transaction" title="https://github.com/changmingxie/tcc-transaction" rel="nofollow">https://github.com/changmingxie/tcc-transaction</a> </td> 
 <td> 4.9K </td> 
 <td> 个人。不支持SpringBoot！！ </td> 
 </tr> 
 <tr> 
 <td> LCN </td> 
 <td> <a href="https://github.com/codingapi/tx-lcn" title="https://github.com/codingapi/tx-lcn" rel="nofollow">https://github.com/codingapi/tx-lcn</a> </td> 
 <td> 3.9K </td> 
 <td> CodingApi团队。依赖太多：Redis、Zookeeper、Consul；目前(2021.02.24)还不支持TCC模式。 </td> 
 </tr> 
 <tr> 
 <td> Hmily </td> 
 <td> <a href="https://github.com/dromara/hmily" title="https://github.com/dromara/hmily" rel="nofollow">https://github.com/dromara/hmily</a> </td> 
 <td> 3.5K </td> 
 <td> 碧桂园。文档完善，SpringCloud与SpringBoot均支持，网上资料多。 </td> 
 </tr> 
 <tr> 
 <td> ByteTCC </td> 
 <td> <a href="https://github.com/liuyangming/ByteTCC" title="https://github.com/liuyangming/ByteTCC" rel="nofollow">https://github.com/liuyangming/ByteTCC</a> </td> 
 <td> 2.5K </td> 
 <td> 北京新奥集团 </td> 
 </tr> 
 <tr> 
 <td> EasyTransaction </td> 
 <td> <a href="https://github.com/QNJR-GROUP/EasyTransaction" title="https://github.com/QNJR-GROUP/EasyTransaction" rel="nofollow">https://github.com/QNJR-GROUP/EasyTransaction</a> </td> 
 <td> 2.2K </td> 
 <td> 个人。（资料少、文档少） </td> 
 </tr> 
 </tbody> 
</table>

预测： Hmily的star数量会逐渐追平并超越LCN和tcc-transaction。

## **功能对比** ##

<table> 
 <tbody> 
 <tr> 
 <td> 框架名称 </td> 
 <td> 幂等性 </td> 
 <td> 嵌套调用 </td> 
 <td> RPC框架支持 </td> 
 <td>SpringBoot支持</td> 
 <td> 支持的事务日志 </td> 
 </tr> 
 <tr> 
 <td> Seata </td> 
 <td> </td> 
 <td> </td> 
 <td> Dubbo。（springcloud：AT模式支持，TCC模式不支持） </td> 
 <td>支持</td> 
 <td> file、DB、redis </td> 
 </tr> 
 <tr> 
 <td> tcc-transaction </td> 
 <td> 不支持 </td> 
 <td> 不支持 </td> 
 <td> 不耦合RPC框架。即：底层使用任何RPC都可以。 但实际上：已对dubbo支持。 </td> 
 <td>不支持</td> 
 <td> file、DB、redis、ZK </td> 
 </tr> 
 <tr> 
 <td>LCN</td> 
 <td>不支持</td> 
 <td>不支持</td> 
 <td></td> 
 <td>支持。（需5.0版本以上）</td> 
 <td></td> 
 </tr> 
 <tr> 
 <td> Hmily </td> 
 <td> 不支持 </td> 
 <td> 不支持 </td> 
 <td> Dubbo、motan、springcloud </td> 
 <td></td> 
 <td> file、DB、redis、mongodb、ZK </td> 
 </tr> 
 <tr> 
 <td> ByteTCC </td> 
 <td> 不支持 </td> 
 <td> 不支持 </td> 
 <td> Dubbo、springcloud </td> 
 <td></td> 
 <td> file </td> 
 </tr> 
 <tr> 
 <td> EasyTransaction </td> 
 <td> 支持 </td> 
 <td> 支持 </td> 
 <td> Dubbo、SpringCloud、Ribbon/Eureka </td> 
 <td></td> 
 <td> DB、Redis </td> 
 </tr> 
 </tbody> 
</table>

说明：是否支持幂等和嵌套调用不重要。原因：

*  我们业务中一般要自己处理幂等（无论框架是否支持幂等）；
 *  若框架不支持嵌套调用，我们不嵌套调用即可。

## **LCN** ##

**说明**

LCN TXC TCC 三种事务模式，且可混合支持。

LCN本质上是一个BestEffors 1PC的框架：大多数情况下，只要应用不Crash就不会导致不一致。

**优点**

*  性能优秀
 *  可靠性强
 *  代码入侵性小  
    在本次对比的所有框架中，LCN实现的分布式事务处理模式，编码复杂性和入侵代码量最低。

**缺点**

*  需额外部署tx-manager服务节点。
 *  由于需要lock资源这种处理方式，如果集中更新某几个热门商品时，LCN的性能衰减量大于TCC模式。
 *  服务超时时，会造成其他服务的资源被锁住，比如支付服务超时过程中，相关商品库存会一直无法操作。
 *  容易导致数据不一致：对于数据出现不一致时，必须修复的情况
    
     *  我们必须要写对应的修复程序。这实际上跟TCC/补偿等工作量一样了
     *  使用BestEffors1PC写的业务代码在出现数据异常时，并不能保证其后续的补偿是可执行的。
     *  举个例子，转账，出现了给别人加钱了，但是自己没有扣钱的数据异常，此时两位客户就有可能立马把钱取出来用掉

## **EasyTransaction** ##

**优点**

*  针对远程调用采用多线程并发处理的模式，性能优化较好
 *  可靠性强
 *  整合简单，无需额外部署事务管理节点

**缺点**

*  对比其他框架，入侵性和编码量是偏大的
 *  RPC请求超时处理尚未实现

## **hmily** ##

**说明**

“采用disruptor框架进行事务日志的异步读写。

**优点**

通过注解的形式声明TCC的的confirm与cancel方法，代码入侵性较小。

**缺点**

*  多线程的锁机制有待优化。
 *  分布式事务中RPC请求串行处理，请求的响应时间长
 *  不可靠：异步写入事务日志就等于TCC是不可靠的

## **easy-transaction** ##

**优点**

*  真正的高性能，对IO做了大量优化，多个独立三方公司横向评测分布式事务框架时，同等场景及同等可靠性保证下性能最佳（可自行验证测试）
 *  理论上只要外部组件不丢数据，在ET内部是不会出现事务不完整的情况（相对于上面一些框架，其原理就不可靠，运行出现异常可以说是必然的）
 *  支持框架幂等，业务程序程序不再需要接管 幂等、调用时序错乱处理等繁琐重复逻辑（这个是一个繁琐重复的工作，貌似只有ET对本项进行了完整支持）
 *  基于扩展的实现，而非基于修改的实现，更易理解，风险更小，功能更强大
 *  支持多种事务形态（TCC,补偿，可靠消息，SAGAs等）混合使用，可按照最适合业务的选择最贴切的事务形态（这时ET创建之初的理念及特点，也是其他框架所不具有的特性）

**缺点**

*  文档很少

[--TCC_--_IT_-CSDN]: https://knife.blog.csdn.net/article/details/122929520