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

简介

说明

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

为什么要使用TCC中间件

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

中间件介绍

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

功能对比

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

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

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创建之初的理念及特点，也是其他框架所不具有的特性）

缺点

• 文档很少

这篇好文章是转载于：学新通技术网