开源背景

在 2017 年和 2018 年的 10 月 24 日，爱可生开源社区出品了 MySQL 分布式中间件 DBLE 和数据复制产品 DTLE。时隔一年，DBLE 和 DTLE 在社区积累了更多的设计经验和用户反馈，有更多的企业和用户在生产环境中使用它们，实现了产品的快速迭代。
目前，随着微服务架构广泛被接受，企业对如何在微服务分布式架构下，实现数据一致性要求也越来越高；TXLE 基于 Saga 模式，实现了分布式架构下的全局事务框架，为数据提供最终一致性；同时贴合金融业务场景设计了服务降级，差错平台对接等金融级功能。
此次开源 TXLE，是延续社区的开源传统，每年一款开源产品。为丰富 MySQL 开源生态添砖加瓦，并希望能切实解决更多企业和用户在金融场景下有关事务一致性的问题。

常见一致性保障手段

两阶段提交

XA 协议最早的分布式事务模型是由 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing（DTP）模型，简称 XA 协议。
基于 XA 协议实现的分布式事务对业务侵入很小。它最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于 XA 协议的分布式事务。XA 协议能够严格保障事务 ACID 特性。
严格保障事务 ACID 特性是一把双刃剑。事务执行在过程中需要将所需资源全部锁定，它更加适用于执行时间确定的短事务。对于长事务来说，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显。因此，在高并发的性能至上场景中，基于 XA 协议两阶段提交类型的分布式事务并不是最佳选择。

柔性事务

如果将实现了 ACID 的事务要素的事务称为刚性事务的话，那么基于 BASE 事务要素的事务则称为柔性事务。BASE 是基本可用、柔性状态和最终一致性这 3 个要素的缩写。
在 ACID 事务中对一致性和隔离性的要求很高，在事务执行过程中，必须将所有的资源占用。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性和隔离性的要求，只要求当整个事务最终结束的时候，数据是一致的。而在事务执行期间，任何读取操作得到的数据都有可能被改变。这种弱一致性的设计可以用来换取系统吞吐量的提升。Saga 就是一种柔性事务实现模式。

（本文中，两阶段提交 和 柔性事务 段落部分引用文章链接：https://www.infoq.cn/article/BAXzcfjRTcgmKisa7JHm?from=groupmessage&isappinstalled=0）

TXLE的架构

TXLE是一款基于 Saga 模式的开源分布式事务框架，主要解决分布式架构下的数据最终一致性。

• txle Agent：txle 在业务端的代理，主要通过对业务的拦截来生成全局事务和子事务，并将相关信息上报至 txle 服务端。
• txle Server：txle 的服务端，主要接收 txle agent 上报的全局事务和子事务信息，并对相关信息进行管理，在发生异常时，对相应的子事务进行协调。
• txle Server Cluster：系统引入 Consul 来保证 txle 服务端的高可用性，以及动态主从切换。
• txle Storage：即 MySQL 数据库实例，用于存储全局事务和子事务相关日志信息、待协调信息和相关系统配置等。
  目前支持整合主流框架 SpringCloud、Dubbo 等；同时提供链路追踪、消息中心、数据转储和监控平台等相关组件，以便保证 txle 服务能够更好地对外提供服务。另外还提供服务降级功能，差错平台等金融级属性，以便在框架遇到严重故障时，还能保证主业务的正常运行。

TXLE的特性

• 支持 Docker 快速部署。
• 多种手段保证数据最终一致性。
• 高性能。单个事务分支对业务的性能影响在 2ms 左右。
• 低侵入。最少 2 个注解即可。
• 支持服务降级。发生不可抗拒因素时，也能保证主业务正常运行。
• 支持差错处理，对接差错平台。
• 支持超时和重试机制。

项目地址

https://github.com/actiontech/txle

文档地址

https://github.com/actiontech/txle-docs-cn

QQ群

TXLE 官方 QQ 社区交流群：696990638