sybase 事务 超时返回_分布式事务

概述

• 目标：解决多个事务一致性的问题。
• 事务：一组操作构成的可靠独立的工作单元；分为本地事务和全局事务：
  • 本地事务：
    • 在单个数据库的本地；
    • 限制在单个进程内的事务；
    • 不涉及多个数据源；
  • 全局事务：
    • 由全局事务管理器进行管理；
    • RM：全局事务管理器通过RM对资源进行控制，资源必须实现XA定义的接口（XA指的是全局事务管理器和资源管理器的接口）；
    • TM：负责协调和事务管理，负责给全局事务管理器提供接口和管理RM

---

XA规范

• AP应用程序；
• TM事务管理器-----和RM通信，第三方组件；
• RM资源管理器（数据库）；
• CRM（communication resource manager）通信资源管理器-----MQ；

2PC步骤：

• preapre阶段：TM向各数据库发送执行SQL命令，但是不提交；
• 提交阶段：
  • 某个RM返回失败或超时没有返回，TM通知回滚；
  • 全部RM返回成功，TM通知提交；

2PC缺陷：

• 同步阻塞：prepare操作会一直占用资源，一直到分布式事务完成，如果其他人要访问该资源，会被阻塞；
• 单点故障：TM是单点，故障则分布式事务失效；
• 事务状态丢失：TM采取双机热备模式，一个节点向RM发送完部分commit消息后，另外一个TM节点不知道哪些RM发送过commit，造成事务状态丢失；
• 脑裂问题：所有commit都发送出去，其中一个库网络故障，事务状态不一致；

3PC步骤：

• 阶段1：发送canCommit，不执行任何sql-------确认环境是OK的；
• 阶段2：发送preCommit，执行sql操作，但不提交；
• 阶段3：收的各个库的执行结果，有任何一个库返回失败，则TM发送回滚操作；全部成功则发送提交；如果RM超时没有收到TM提交或回滚操作，默认TM挂了，各个事务自行回滚；

---

方案

• XA方案（两阶段提交）

事务管理器TM协调RM进行提交或回滚，使用springboot+JTA实现，一般性能较低，不使用。

• TCC方案
  • 针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。业务逻辑每个分支都要实现try，confirm，cancel接口。
    • Try 阶段主要是对业务系统做检测及资源预留--------加锁，冻结资源；
    • Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功；
    • Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消（）undo_log），预留资源释放；
    • 隔离性，一致性要求比较高的场景，如金融相关的。需要自己实现confirm和cancel逻辑；

• 消息发送一致性

• 最终一致性方案1----本地消息服务
  • 一直不断重复发送，直到B系统执行成功；
  • B系统保证幂等性；
  • 太依赖本地消息数据，高并发有压力；
  • 耗时；

• 最终一致性方案2-----独立消息服务
  • A系统先发一个prepare消息到MQ，prepare消息发送失败直接取消执行；
  • 消息发送成功执行本地事务，执行成功告诉mq发行确认消息，执行失败告诉mq回滚消息------mq长时间没有收到确认消息会回调A系统，A系统因为已经执行本地事务，所以直接向mq发送确认消息；
  • 如果mq消息确认后，B系统会消费该消息，执行本地事务；
  • B系统执行失败，B系统要一直不断重复执行直到成功或者通过zk让A系统再次发送消息；
  • 耗时；

• 最大努力通知
  • 业务活动的主动方向业务活动的被动方发送消息(允许丢失数据);
  • 被动方的处理结果不影响主动方；
  • 被动方向主动方查询数据，恢复丢失的业务数据；
  • 对时间敏感度比较低的场景；
  • 和最终一致性相比，最大努力通知有可能会失败；