Interview preparation -- spring cloud seata

分布式事务

事物ACID特性

• A（Atomic）：原子性，构成事物的所有操作，要么全部成功，要么全部失败，不存在部分成功或失败情况
• C（Conststency）：一致性，在事物完成时候，所有数据必须保持一致
• I（Isolation）：隔离性，并发的两个事物的执行相互不干扰，一个事物不能看到其他事物的中间状态
• D（Durability）：持久性，事物完成之后对系统的影响是永久性的

BASE理论

• BASE是Basicallly Available（基本可用），Soft state（软状态），Eventually consistent（最终一致性）

• BASE理论是对CAP一致性 和可用性的一个权衡，核心思想是无法做到强一致性，但每一个应用可以根据自身业务特点做到最终一致性

• 基本可用：

  • 分布式系统出现不可预知故障时候，允许损失一部分可用性
  • 例如，查询速度可以延迟
  • 非必要功能可以先引导到降级页面

• 软状态：

  • 允许系统数据存在中间状态，并且改中间状态的存在不会影响系统整体可用性

• 最终一致性：

  • 最终一致性强调所有数据副本，可以在一定时间内不一致，能够在一段时间同步之后达到一致性的目的

分布式事务解决方案

2PC

• 2PC即两阶段提交协议，是将整个事物流程分为两个阶段，P是指准备阶段，C是提交阶段

  • 准备阶段：事物管理器TC，给每个参与者资源管理器RM发送Prepare消息，每个事物参与者在本地执行事物，但是不提交事物，并且记录本地日志Undo/Redo日志，
    • Undo日志记录的是修改之前的数据，Redo记录的是修改之后的数据。
  • 提交阶段：如果事物管理器TC收到任何参与者的失败消息，直接给每一个参与者发送回滚（Rollback）消息；否则，发送提交（Commit）消息；资源管理器RM根据事物管理器TC发送的指令执行提交或者回滚。并且释放事物处理过程中使用的资源。
    

• 2PC的缺点很明显

  • 所有流程同步阻塞，对任务一次指令全部取得回复才能进行下一步，期间资源都处于锁定状态
  • 任务节点失败，超时都会导致全局失败
  • 事物协调者，也就是事物管理器TC出现故障，例如如果在第二阶段出现故障，那么所有参与者的资源会一直处于锁定状态。
  • 脑裂导致数据不一致问题：在二阶段时候，事物管理者发送提交指令，但是因网络故障导致部分节点收到，部分节点没收到，此时没有收到的节点无法提交事物导致各节点之间数据的不一致问题。

3PC

• 3PC 三阶段提交协议，是2PC的一个改进版本，利用超时机制解决同步阻塞问题，三阶段具体如下
  • CanCommit（询问提交）：事物协调者发送事物执行请求给参与者，是否可以完成指令，参与者只对资源检查看是/否能完成，如果回复否或者超时则结束
  • PreCommit（准备阶段）：协调者收到所有参与者的反馈，如果所有反馈都是true，则发送preCommit指令，参与者收到后，执行事务但是不提交，记录Undo/Redo 日志，然后返回ACK响应等到下一步指令
  • DoCommit（提交或者回滚）：依据上一步中的反馈，如果有任何一个参与者没有返回ACK超时，或者任何一个参与者返回执行失败，那么事务协调者发送rollback指令给所有参与者，否则发送commit指令。

Seata 中分布式事务解决方案

Seata-AT模式

• AT模式是一种无侵入的分布式事务解决方案，用户只需要关注自己的SQL，AT模式中用户的SQL就是第一阶段，Seata-AT模式会给你自动生成事务二阶段提交与回滚，是2PC的一个应用

• 一阶段：Seata拦截业务SQL，解析SQL，找到要更新的数据，记录Undo，然后执行业务SQL，在记录Redo，最后生成行锁，这些操作都是在本地数据库事务内完成。

• 二阶段：负责整体回滚与提交，如果之前一阶段中有本地事物没有通过，那么执行全局回滚，否则全局提交，回滚用到的是第一阶段的Undo log，通过日志生成反向更新SQL并且执行。事物完成后释放锁等资源，删除日志。

Seata的TCC模式

• TCC是分布式事务二阶段提交协议，Try-Confirm-Cancel，
  • try：对业务资源的检查并预留
  • Confirm：对业务进行处理并进行提交，即commit操作，职业try成功，这个步骤一定成功
  • Cancel：对业务处理进行取消，即回滚操作，高部长对Try预留资源的释放。

• Tcc特点：
  • 侵入性强，并且需要自己实现相关业务事务控制逻辑，try，confirm，cancel都是自己实现的业务逻辑因此业务侵入性很大，设计复复杂，不依赖数据库，因此实现跨库，跨应用资源管理。适合复杂业务场景下的分布式事务问题
  • 整个过程没有锁，性能强

Seata 中Saga模式

• Seata中Saga模式提供长事务解决方案，在Saga模式中，业务流程中每个参与者都只提交他们自己的本地事物。当出现一个参与者失败，则补偿前面已经提交过的参与者。
  • 一阶段正向执行服务 和二阶段反向补偿服务读由业务开发实现。

• Saga模式与TCC的区别在于：

  • TCC的Try与Confirm，Cancel 都由子系统提供具体的业务方法
  • Saga模式中一阶段处理 与 二阶段补偿都由事务协调者TC 实现具体的业务

• Saga模式存在的意义：

  • 在一些特殊的项目中，比如老系统，封闭系统，多语言开发的其他微服务参与系统，我们无法去修改子系统，因此无法用AT 与TCC，为了解决这种问题，引入了Saga模式。

Seata 的XA模式

XA协议

• XA规范是X/Open组织定义的分布式事务处理（DTP，Distributed Transaction Processing）
• XA规范描述了全局事务管理器 与 局部的资源管理器直接的接口，XA规范的目的允许多个资源（比如数据库，应用服务器，消息队列）在同一个事物中访问，这样可以使ACID属性跨应用程序并且保持有效。
• XA规范使用两阶段提交，保证所有资源同时提交或者回滚任何特定事物
• XA协议定义了三个角色
  • AP：即应用程序，可以理解为使用XA模式的分布式事务程序
  • RM：资源管理器，可以理解为事物的参与者，在XA模式下，指一个数据库的实例（MySql），通过资源管理器对改数据库进行控制，资源管理器控制分支事物
  • TM：事物管理器，负责协调和管理事物，并且控制全局事物的提交，回滚，协调各个RM
  • XA模型下，定义TM 和RM之间通讯的接口规范叫XA规范，也就是依赖数据库的实现来达到全局的原子性操作。简单理解就是数据库提供了2PC的接口协议，基于数据库的XA协议实现的2PC称为XA方案。

Seata的XA模式

• Seata 中XA模式，利用数据库中XA接口的实现来完成

1. TM向TC发起（begin）全局事物，TC生成全局事物XID
2. TM吧代表全局事物的XID绑定到分支事物上
3. RM向TC注册，将分支事物关联到XID代表的全局事物中，RM分别执行自己的事物但是不提交
4. RM将分支事物的执行结果上报给TC
5. TC根据每一个RM的结果信息来决定，发送分支提交（Branch Commit） 或者回滚（Branch Rollback）命令给RM

• 最终还是2阶段提交
• 执行阶段：
  • 可回滚：业务SQL操作房子XA分支中进行，由资源对XA协议的支持保证可以回滚（类似MYSQL的本地事务）
  • 持久化：XA分支完成后，执行XA prepare，同样由资源对XA协议的支持保持持久化
• 完成阶段：
  • 分支提交：执行XA分支的Commit（mySql的commit）
  • 分支回滚：执行XA分支的rollback（mySql的rollback）

Seata-XA适用场景

• 本质上Seata已经支持AT，TCC，Saga三种都是补偿型的事务
• 补偿型事物处理机制是依赖 资源的（RM），无法做到全局一致性，也就是必然有中间状态，比如AT模式在失败回滚这一瞬是可以查询到脏数据的，更别伦TCC，Saga这种业务支持模式
• XA协议不要去事物资源本身就提供规范和协议本身的支持，也就是利用现有关系型数据库实现的XA协议来保证数据的全局一致性，这样XA协议就区别与另外三个是一个强一致性的分布式事务解决方案
  • 无业务入侵：和AT一样，XA模式是利用关系型数据库来完成
  • 数据库支持广：XA协议是先有主流数据库支持的
  • 多语言支持容易：不用SQL解析，XA模式对RM的要求少
  • 基于传统XA应用迁移：传统的基于XA协议的应用，迁移到Seata平台，使用XA模式更平滑

TCC的空回滚问题解决方案

• 空回滚的问题由来：
  • TC对TM发送全局事物开始指令，并且生产XID
  • TM将事物参与者RM的信息以及获取的XID一起注册到TC上
  • 此时本来应该RM执行Try，但是由于某些故障导致RM没有收到TM的Try指令
  • 接着TC会发送rollback的指令给TM。
  • TM发送给每一个RM 指令 rollabck
  • 这时候A的网络恢复，导致了空回滚

• 解决办法：
• 每次执行事务都增加一个TCC控制表的数据，每个事物对应一个XID，并且每次注册一个事物参与者RM在执行完Try后都添加一条数据RID并且关联上XID。在执行回滚的时候，查询XID对应的所有RM信息，有则回滚没有就不回滚。

TCC幂等性问题

• 参与者A执行完二阶段本地事物后，由于网络原因，无法同步到TC，导致TC不断的发送commit指令进行重试而导致A本地事物的重复执行。
• 解决方式：
  • 同样在TCC事物表中，增加一个状态字段，status。三个值：
  • tried：1， committed 2， rollbacked 3
  • 在二阶段提交的时候，执行完confire/cancel 后状态改为commited/rollbacked，每次需要执行之前都确认一次状态在执行即可解决

最大努力通知型方案

• 满足两点：
  • 有一定的消息重复通知机制
  • 消息校对机制。
• 落地方案：
  • 对于公司内部系统。可以通过MQ系统直接订阅消息的方式来完成。MQ的ACK机制以及重试机制会帮住完成最大努力推送。EX：统一支付系统给 各个子系统推送支付结果用MQ
  • 对于公司外部系统。不能MQ形式，那么需要每一个接入系统的公司提供一个接口，微信通过这个接口来完成消息的同步。EX：微信&支付宝通过统一支付系统提供的参数来完成支付回调通知。