【分布式事务】常见分布式事务简述

分布式事务 常见分布式事务简述

一、事务

1. ACID

• A 原子性 Atomicity 英[ˌætəˈmɪsəti]
  • either all happen or none happen. These changes include database changes, messages, and actions on transducers.
• C 一致性 Consistency 英[kənˈsɪstənsi]
  • A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constrains associated with the state. This requires that the transaction be a correct program.
• I 隔离性 Isolation 英[ˌaɪsəˈleɪʃn]
  • Even though transactions execute concurrently, it appears to each transaction, T, that others executed either before T or after T, but not both.
• D 持久性 Durability 英[ˌdjʊərəˈbɪlɪti]
  • Once a transaction completes successfully(commits), its changes to the state survive failures.

Transaction Processing Book

2. 分布式事务目前支持类型

• XA
  • 强一致性，数据库基础上进行的封装和增强
  • XA 事务又叫两阶段事务（2PC two-phase commit protocol）
• BASE柔性事务
  • 最终一致性（利用超时终止、补偿等业务方式，达到最终一致）
  • 常见模式
    • TCC 手动补偿
    • AT 自动补偿
    • SAGA

二、XA 分布式事务协议

• X/Open国际联盟有限公司维护
• 2PC
  • prepare 等待全部SQL执行完成
  • commit 一次性提交已执行完的SQL
• AP RM TM
  • AP 应用
  • RM 资源管理器（数据库、文件系统）
  • TM 事务管理器
• 常见框架
  • atomikos
    • 官网
    • The Greek word ‘atomikos’ means atomic (in the sense of all-or-nothing), referring to this essential property of reliable transaction management
  • narayana
    • 官网
    • JBoss Transaction Manager (Narayana)
    • With over 30 years of expertise in the area of transaction processing, Narayana is the premier open source transaction manager
  • Bitronix
  • seata
    • 官网
    • Seata 是一款阿里巴巴开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

1. 优势

• 强一致性，基于数据库级别
  • Mysql5.0.3 innodb 引擎开始支持 XA
  • 第一代MQ都支持XA
• 有成熟的支持框架、X/Open标准
• 业务侵入性低

2. 劣势

• XA 会让性能下降很多，3倍或者更多 （commit 需要等待全部 prepare）
• 跨库业务访问需要让全局串行化，才能保证全局看到的一致
• 依赖 TM RM，框架比较重

3. 需要注意的问题

• TM 存在单点故障问题，需要保证高可用
• 没有百分百的数据一致，会存在各种失败异常的问题，需要做好监控，人工及时处理

4. 使用场景

• 微服务内部使用，无跨库问题
• 复杂业务开发，不过多考虑性能问题
• 减少业务开发人员对底层事务的感知

三、BASE柔性事务

• BASE
  • BA 基本可用性 Basically Available
  • S 柔性状态 Soft State
  • E 最终一致性 Eventual Consistency
• TCC （Try Confirm Cancel）
  • Try 业务检查、预览业务资源（数据库操作进行业务拆分）
  • Confirm Try成功Confirm必须能成功。继续做重试，或者回滚掉
  • Cancel 释放预留的业务资源
• AT
  • 自动生成反向SQL
• SAGA
  • 相比TCC没有TRY直接提交事务
  • TCn 模式 TRY Cancel Cancel Cancel
• 常见框架
  • Seata
  • hmliy

1. 优势

• 极大的提高了吞吐量，事务不等待
• 不依赖 TM RM，技术更强、业务更重
• 对一致性的要求降低，可以更灵活的解决问题
• AT
  • 自动补偿，减少事务部分代码编写
• SAGA
  • 一阶段提交

2. 劣势

• 复杂情况下，对业务设计要求高
• 业务侵入性强
• AT
  • 复杂 SQL 难以支持
• SAGA
  • 复杂情况下，对回滚操作设计要求高，所有业务设计都得支持幂等
  • 每个 Cancel 独立编写

3. 需要注意的问题

• 幂等设计很重要（可能会重试，保证幂等）
• TCC
  • 允许空回滚（TRY没完成是Cancel可以判断不做）
  • 防悬挂控制（TRY一定要先执行，或者看是否有Cancel的，TRY可以不做）（防网络抖动）

4. 使用场景

• 适合需要高吞吐的场景
• 适合不想要依赖 TM RM 的场景