所有分类
  • 所有分类
  • 未分类

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

简介

说明

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

为什么要使用TCC中间件

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

中间件介绍

中间件名称Github地址star数量简介
Seatahttps://github.com/seata/seata18.3K阿里。TCC模式仅支持dubbo,不支持feign。
tcc-transactionhttps://github.com/changmingxie/tcc-transaction4.9K个人。不支持SpringBoot!!
LCNhttps://github.com/codingapi/tx-lcn3.9KCodingApi团队。依赖太多:Redis、Zookeeper、Consul;目前(2021.02.24)还不支持TCC模式。
Hmilyhttps://github.com/dromara/hmily3.5K碧桂园。文档完善,SpringCloud与SpringBoot均支持,网上资料多。
ByteTCChttps://github.com/liuyangming/ByteTCC2.5K北京新奥集团
EasyTransactionhttps://github.com/QNJR-GROUP/EasyTransaction2.2K个人。(资料少、文档少)

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

功能对比

框架名称幂等性嵌套调用RPC框架支持SpringBoot支持支持的事务日志
SeataDubbo。(springcloud:AT模式支持,TCC模式不支持)支持file、DB、redis
tcc-transaction不支持不支持不耦合RPC框架。即:底层使用任何RPC都可以。 但实际上:已对dubbo支持。不支持file、DB、redis、ZK
LCN不支持不支持支持。(需5.0版本以上)
Hmily不支持不支持Dubbo、motan、springcloudfile、DB、redis、mongodb、ZK
ByteTCC不支持不支持Dubbo、springcloudfile
EasyTransaction支持支持Dubbo、SpringCloud、Ribbon/EurekaDB、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创建之初的理念及特点,也是其他框架所不具有的特性)

缺点

  • 文档很少

0

评论0

请先

显示验证码
没有账号?注册  忘记密码?

社交账号快速登录