原文网址：分布式事务--TCC的中间件--选型/对比_IT利刃出鞘的博客-CSDN博客
简介说明
本文介绍分布式事务的TCC的一些中间件。包括：Seata，TCC-transaction、ByteTCC、Himly、EasyTransaction、LCN
为什么要使用TCC中间件
感知各个阶段的执行情况以及推进执行下一个阶段的这些事情，不太可能自己手写实现，太复杂了。
中间件介绍| 中间件名称 | Github地址 | star数量 | 简介 |
| Seata | https://github.com/seata/seata | 18.3K | 阿里。TCC模式仅支持dubbo，不支持feign。 |
| tcc-transaction | https://github.com/changmingxie/tcc-transaction | 4.9K | 个人。不支持SpringBoot！！ |
| LCN | https://github.com/codingapi/tx-lcn | 3.9K | CodingApi团队。依赖太多：Redis、Zookeeper、Consul；目前(2021.02.24)还不支持TCC模式。 |
| Hmily | https://github.com/dromara/hmily | 3.5K | 碧桂园。文档完善，SpringCloud与SpringBoot均支持，网上资料多。 |
| ByteTCC | https://github.com/liuyangming/ByteTCC | 2.5K | 北京新奥集团 |
| EasyTransaction | https://github.com/QNJR-GROUP/EasyTransaction | 2.2K | 个人。（资料少、文档少） |
预测： Hmily的star数量会逐渐追平并超越LCN和tcc-transaction。
功能对比| 框架名称 | 幂等性 | 嵌套调用 | RPC框架支持 | SpringBoot支持 | 支持的事务日志 |
| Seata | Dubbo。（springcloud：AT模式支持，TCC模式不支持） | 支持 | file、DB、redis | ||
| tcc-transaction | 不支持 | 不支持 | 不耦合RPC框架。即：底层使用任何RPC都可以。 但实际上：已对dubbo支持。 | 不支持 | file、DB、redis、ZK |
| LCN | 不支持 | 不支持 | 支持。（需5.0版本以上） | ||
| Hmily | 不支持 | 不支持 | Dubbo、motan、springcloud | file、DB、redis、mongodb、ZK | |
| ByteTCC | 不支持 | 不支持 | Dubbo、springcloud | file | |
| EasyTransaction | 支持 | 支持 | Dubbo、SpringCloud、Ribbon/Eureka | DB、Redis |
说明：是否支持幂等和嵌套调用不重要。原因：
我们业务中一般要自己处理幂等（无论框架是否支持幂等）；若框架不支持嵌套调用，我们不嵌套调用即可。 LCN
说明
LCN TXC TCC 三种事务模式，且可混合支持。
LCN本质上是一个BestEffors 1PC的框架：大多数情况下，只要应用不Crash就不会导致不一致。
优点
性能优秀可靠性强代码入侵性小
在本次对比的所有框架中，LCN实现的分布式事务处理模式，编码复杂性和入侵代码量最低。
缺点
需额外部署tx-manager服务节点。由于需要lock资源这种处理方式，如果集中更新某几个热门商品时，LCN的性能衰减量大于TCC模式。服务超时时，会造成其他服务的资源被锁住，比如支付服务超时过程中，相关商品库存会一直无法操作。容易导致数据不一致：对于数据出现不一致时，必须修复的情况
我们必须要写对应的修复程序。这实际上跟TCC/补偿等工作量一样了使用BestEffors1PC写的业务代码在出现数据异常时，并不能保证其后续的补偿是可执行的。举个例子，转账，出现了给别人加钱了，但是自己没有扣钱的数据异常，此时两位客户就有可能立马把钱取出来用掉 EasyTransaction
优点
针对远程调用采用多线程并发处理的模式，性能优化较好可靠性强整合简单，无需额外部署事务管理节点
缺点
对比其他框架，入侵性和编码量是偏大的RPC请求超时处理尚未实现 hmily
说明
“采用disruptor框架进行事务日志的异步读写。
优点
通过注解的形式声明TCC的的/confirm/i与cancel方法，代码入侵性较小。
缺点
多线程的锁机制有待优化。分布式事务中RPC请求串行处理，请求的响应时间长不可靠：异步写入事务日志就等于TCC是不可靠的 easy-transaction
优点
真正的高性能，对IO做了大量优化，多个独立三方公司横向评测分布式事务框架时，同等场景及同等可靠性保证下性能最佳（可自行验证测试）理论上只要外部组件不丢数据，在ET内部是不会出现事务不完整的情况（相对于上面一些框架，其原理就不可靠，运行出现异常可以说是必然的）支持框架幂等，业务程序程序不再需要接管 幂等、调用时序错乱处理等繁琐重复逻辑（这个是一个繁琐重复的工作，貌似只有ET对本项进行了完整支持）基于扩展的实现，而非基于修改的实现，更易理解，风险更小，功能更强大支持多种事务形态（TCC,补偿，可靠消息，SAGAs等）混合使用，可按照最适合业务的选择最贴切的事务形态（这时ET创建之初的理念及特点，也是其他框架所不具有的特性）
缺点
文档很少
