分布式事务选型

## 分布式事务选型

### 选型依据:

- 多语言支持
- 微服务框架兼容程度
- 关系型数据库-MQ事务的支持
- 性能与稳定性以及是否支持高可用
- 业务代码侵入性
- 可拓展性
- 社区活跃度及影响力

------

### GTS概览

####     针对不同的应用场景,GTS主要提供标准模式(AT)和自定义模式(MT)两种事务模式.

- **AT模式**: GTS 最主要的事务模式,通过 GTS 基于 DRDS/RDS 数据源,对 sql 语句提供分布式事务的支持.他帮助应用以最小的改动代价来实现数据库的事务功能.AT 模式适用于 DRDS 分库分表/多数据库数据源/跨进程的多数据库数据源等几乎任何 DRDS 应用场景下的分布式事务.
- **MT模式**: 提供给用户的一种可介入两阶段提交过程的一种模式.在这种模式下,用户可以根据自身的业务场景的需求自定义在 GTS 两阶段提交的过程中每阶段的具体行为.MT 模式提供了更多的可能性和灵活性,以达到特殊场景下的自定义特殊功能实现.**MT 模式不依赖于数据库,几乎满足任何事务场景.**

####     在 AT 和 MT 两种模式下,GTS 又提供了三种具体的使用方式:

- **AT模式下,使用注解接入分布式事务**

  这种方式只需要代码中依赖 GTS 的 SDK 即可.在希望引入分布式事务的方法上,仅需一行注解即可.适用场景包括 数据库事务/MQ消息事务/EDAS的服务事务一级多场景混合型事务方案．

- **AT模式下,DRDS 接入分布式事务**

  使用时无需 @TxcTransaction 注解,且无需引入 GTS 的 SDK,仅需要在用户的 SQL 语句中使用 select last_txc_xid() 这条 SQL 语句接入 GTS 分布式事务.通过这种方式,用户在使用 DRDS 实现分库分表后,就可以使用 GTS 实现和传统单机数据库一致的分布式事务.

- **MT模式下,两阶段提交接入分布式事务** 

  允许应用介入事务提交两阶段提交,分为补偿性事务和预留型事务:

  1. 补偿性事务:应用在第一阶段实现具体的业务操作,第二阶段实现提交或回滚操作.
  2. 预留型事务:应用在第一阶段预留业务资源,第二阶段实现真正的业务逻辑或者回滚.

####     **GTS-API**

​    为满足多样的开发环境,GTS提供了在非Spring框架下直接使用API开启并管理全局事务的方式.

[API参考]: https://help.aliyun.com/document_detail/62673.html?spm=a2c4g.11186623.6.587.734668e0nuOJ28

​    

### GTS优缺点

####     多语言支持

​    针对多语言环境的支持,官方并没有给出具体的说明,所有的官方示例及文档相关都是以JAVA为基础的展现.

####     微服务框架兼容程度

​    GTS几乎兼容当前所有微服务框架,并支持跨服务的分布式事务(无论您使用的是 Dubbo、EDAS,还是 Spring Cloud 服务框架，都可以接入事务).

####     关系型数据库-MQ事务的支持    

weihu    支持 RDS、MySQL、PostgreSQL、OceanBase、Petadata 等多种数据源,并可以配合 EDAS、Dubbo、Spring Cloud 及多种私有 RPC 框架使用,同时还兼容 MQ 等中间件产品.

####     简单易用、侵入性极低

​    GTS 让应用开发者不再需要考虑复杂的事务问题,仅需简单配置及一句 GTS 注解（@TxcTransaction）就能帮您轻松实现分布式事务,对已有业务代码无侵入.

####     高性能

​    GTS 通过大量创新,解决了事务 ACID 特性与高性能、高可用、低侵入不可兼得的问题.单事务分支的平均响应时间在 2ms 左右,3 台服务器组成的集群可以支撑 3 万 TPS 以上的分布式事务请求.

####     高可用、高可靠

​    GTS 解决了 XA 事务协调器单点问题,在应用宕机、节点故障等各类异常情况均可保证数据严格一致.中间状态多份落盘存储,经过严格断电测试,严格保证数据一致性.

####     社区活跃度及影响力

​    因为GTS为商业化组件,产品影响力广泛;由官方团队维护.

####     环境要求

​    依赖阿里云服务器,且无法再本地测试.

------

### Seata概览    

​    Seata作为GTS的开源版本,目前最新的版本0.7.1(官方目前推荐版本,生产可用版本v1.0.0),同GTS一样,Seata目前也有AT和MT两种模式,与GTS有所不同是,Seata不需要在强制依赖阿里云服务器和分布式关系数据库.

####     混合模式

​    因为AT 和MT 模式的分支从根本上行为模式是一致的,所以可以完全兼容,即,一个全局事务中,可以同时存在AT 和MT 的分支.这样就可以达到全面覆盖业务场景的目的:AT 模式可以支持的，使用AT 模式;AT 模式暂时支持不了的,用MT 模式来替代.另外,自然的,MT 模式管理的非事务性资源也可以和支持事务的关系型数据库资源一起,纳入同一个分布式事务的管理中。

####     应用场景的远景

​    我们设计的初衷:一个理想的分布式事务解决方案是不应该侵入业务的.MT 模式是在AT 模式暂时不能完全覆盖所有场景的情况下,一个比较自然的补充方案.我们希望通过AT 模式的不断演进增强,逐步扩大所支持的场景,MT 模式逐步收敛.未来,我们会纳入对XA 的原生支持,用XA 这种无侵入的方式来覆盖AT 模式无法触达的场景.


### Seata优缺点

####     多语言支持

​    就目前来说,依赖于分布式服务框架.但是在与官方开发人员沟通过程中了解到:AT 模式的事务相关操作基于标准的JDBC接口(GTS&Seata都是对于业务SQL的解析),c#(.NET)可以实现分布式事务的相关操作;像PHP/PY实现难度较大,官方也没给出明确答复.但是在近期的微服务开源生态报告中,Seata向社区征集Seata 客户端go版本开发与测试.

####     微服务框架兼容程度

​    SC/SCA/Dubbo

####     关系型数据库-MQ事务的支持    

​    因为AT 涉及SQL 的解析,所以在不同类型的数据库上工作,会有一些特定的适配.当前版本仅支持mysql,Seata 将在0.8.0 版本发布对oracle的支持和SAGA模式.

​    MQ的支持需要用MT模式来进行拓展.

####     简单易用、侵入性极低

​    同GTS一样,只需一个注解即可实现.

####     高可用、高可靠、高性能

​    虽然Seata是GTS的开源版本,但当前未得到大规模应用(即生产可用版本),性能和可靠性方面未得到验证.

​    高可用方面,官方在示例中提供HA示例.

####     社区活跃度及影响力

​    紧随SCA的开源不久后开源,社区活跃度高影响力大.

### Roadmap

#### v0.1.0

- Microservice framework support: Dubbo
- Database support: MySQL
- Spring AOP annotation Support
- Transaction coordinator: Stand-alone Server

#### v0.5.x

- Rename Fescar to Seata
- Microservice framework support: SOFA, Spring Cloud
- Support TCC(Try Confirm Cancel) transaction mode
- Dynamic configuration
- Services discovery

#### v0.6.x

- Transaction coordinator: Cluster Server with HA

#### v0.8.x

- Promethus support
- Management console: Monitor, Deployment, Upgrating, etc.

#### v1.0.0

- Production ready

#### v1.5.x

- Database support: Oracle, PostgreSQL, OceanBase
- Optimization of conflict datas
- Independent of Spring Annotation
- Multiple source of data transaction support: MessageQueue(RocketMQ), HBase, Redis, etc.

#### v2.0.0

- XA transaction mode support

**官方概览:**[https://github.com/seata/seata/wiki/%E6%A6%82%E8%A7%88](https://github.com/seata/seata/wiki/概览)

**为了更好的服务社区，对使用Seata 用户开启信息登记**:*https://github.com/seata/seata/issues/1246*

------

### TX-LCN概览

​    当下流行的分布式事务解决方案之一.支持三种模式LCN、TCC、TXC三种事务模式.

###     LCN模式

- 原理

  ​    LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。

- 特点

  1. 性能优秀,可靠性强.
  2. 兼容性强,支持所有的关系型数据库事务,支持多数据源.
  3. 业务入侵性低,使用时只需添加相应注解即可.
  4. 需额外部署Tx-Manager节点,增加相应的运维成本.
  5. 由于需要lock资源这种处理方式,在更新某几个热点商品时LCN的性能衰减量大于TCC模型.
  6. 服务超时时,会造成其他服务的资源被锁住.如支付服务超时,相关商品的库存会一直无法操作.

#### 　TCC模式

- 原理

  ​    TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。

- 特点

  1. 该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。
  2. 该模式对有无本地事务控制都可以支持使用面广。
  3. 数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。

#### 　TXC模式

- 原理

  ​    TXC模式命名来源于淘宝，实现原理是在执行SQL之前，先查询SQL的影响数据，然后保存执行的SQL快走信息和创建锁。当需要回滚的时候就采用这些记录数据回滚数据库，目前锁实现依赖redis分布式锁控制。

- 特点

  1. 该模式同样对代码的嵌入性低。
  2. 该模式仅限于对支持SQL方式的模块支持。
  3. 该模式由于每次执行SQL之前需要先查询影响数据，因此相比LCN模式消耗资源与时间要多。
  4. 该模式不会占用数据库的连接资源。

#### 混合模式

​    类似Seata,LCN也支持混合模式,每个事务分支可根据自身业务特点选择合适的模式.

​    另外,LCN还支持事务模式和通讯协议的拓展.

### LCN优缺点

####     多语言支持

​    支持JAVA,且没提供拓展接口.

####     微服务框架兼容程度

​    SC/Dubbo

####     关系型数据库-MQ-NoSQL事务的支持    

​    支持关系型数据、NoSQL数据库.但未指出明确信息.

​    MQ的支持需要用TCC模式来进行拓展.

####     简单易用、侵入性低

​    需要业务发起方和被调用发添加相应注解.

####     高可用、高可靠、高性能

​    支持负载均衡与集群化部署,高性能与高稳定性.

####     社区活跃度及影响力

​    活跃度相对较低,Github最近一次提交在五个月前.Github issues回复率低.

​    

**总结:根据业务场景选取一致性模型,一套业务中可能用到不同的模型.不是所有的业务场景都需要强一致性,避免强一致性带来的性能损耗.最终一致性要考虑是否确定时间窗口,反馈给客户的体验,业务是否要基于绝对准确值做业务变化.**

​