柔性事务

简介

• 柔性事务遵循BASE，针对大型分布式系统，牺牲强一致，获得高可用。
• 高可用=系统构建在多机=分布式系统->高性能。
• 通过补偿实现：正向补偿、反向补偿。

服务化传统事务

TCC

服务化的两阶段提交，补偿型事务。

高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景

• Try阶段执行成功，则执行Confirm，否则执行Cancel。
• 如果try成功，默认comfirm一定成功，可以通过重试实现。

两个阶段

• Try阶段。
  • 完成业务检查（一致性），预留资源（准隔离性）。
• Confirm阶段。
  • 提交业务，不做检查，只是用预留资源执行操作。
  • 需要幂等。
• Cancel阶段。
  • 取消业务，归还预留资源。
  • 需要幂等。

对比二阶段提交

• 二阶段提交：
  • 强一致，整个过程一直持有资源锁。
  • 资源层面事务，对开发屏蔽。
• TCC：
  • 最终一致，只预留资源不会一直持有锁。
  • 业务层面事务，未对开发屏蔽。

消息补偿

事务消息

• 消息中间件记录了整个事务的状态。
• 第一阶段：保证本地事务1执行、发送消息同时成功或者失败。
• 第二阶段：执行本地事务2。本地事务2执行失败的两个方案：
  • 重新消费MQ。较为简单，但需要保证幂等。
  • 回滚事务1。
• 

SAGA

长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统

• SAGA

数据库补偿

运维简单

• 数据库记录整个事务状态。
• 第一阶段：
  • 执行成功，更新事务状态为第一阶段已执行。
  • 执行失败，删除事务记录，整个事务失败。
• 第二阶段：
  • 执行成功，删除事务记录，整个事务成功。
  • 执行失败，为了简化吞掉异常，事务伪成功。
• 补偿任务筛选超时事务，调用业务方check接口校验事务状态。
  • 校验已完成，删除事务记录，事务成功。
  • 校验未完成，重试第二阶段。
• 二阶段和check接口需要保证幂等，防止二阶段执行成功但是删除事务状态失败，check之后二阶段重试。

其他方案

• 避免事务回滚。不回滚也能满足业务要求。
  • 比如先写辅助表再写主表，读的时候先读主表再读辅助表。
  • 辅助表写入幂等。
• 事件溯源。如库存预减明细表，计算存储的时候考虑库存快照+明细表，避免对一条库存数据抢锁。
• 乐观锁。版本号校验，不匹配重试。

参考

• TCC两阶段补偿型
• 柔性事务
• seata三种模式， seata官网