简介
说明
本文介绍分布式事务的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与cancel方法，代码入侵性较小。
缺点
- 多线程的锁机制有待优化。
- 分布式事务中RPC请求串行处理，请求的响应时间长
- 不可靠：异步写入事务日志就等于TCC是不可靠的
easy-transaction
优点
- 真正的高性能，对IO做了大量优化，多个独立三方公司横向评测分布式事务框架时，同等场景及同等可靠性保证下性能最佳（可自行验证测试）
- 理论上只要外部组件不丢数据，在ET内部是不会出现事务不完整的情况（相对于上面一些框架，其原理就不可靠，运行出现异常可以说是必然的）
- 支持框架幂等，业务程序程序不再需要接管 幂等、调用时序错乱处理等繁琐重复逻辑（这个是一个繁琐重复的工作，貌似只有ET对本项进行了完整支持）
- 基于扩展的实现，而非基于修改的实现，更易理解，风险更小，功能更强大
- 支持多种事务形态（TCC,补偿，可靠消息，SAGAs等）混合使用，可按照最适合业务的选择最贴切的事务形态（这时ET创建之初的理念及特点，也是其他框架所不具有的特性）
缺点
- 文档很少
请先 ！