分布式事务理论

分布式事务分类

• 柔性事物
  • 不要求强一致性，而是要求最终一致性，允许有中间状态，也就是 BASE 理论，换句话说，就是 AP 状态
  • 有业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，适合长事务
  • 柔性事务：补偿型、异步确保型、最大努力通知型
  • 柔型事务：TCC/FMT、SAGA(状态机模式、Aop模式)、本地事务消息、消息事务(半消息)

• 刚性事物
  • 通常无业务改造，强一致性，原生支持回滚、隔离性，低并发，适合短事务
  • 刚性事务满足足 CAP 的 CP 理论，要使分布式事务，达到像本地式事务一样，具备数据强一致性，从 CAP 来看，就是要达到 CP 状态
  • XA 协议 ( 2PC、JTA、JTS)、3PC，但由于同步阻塞，处理效率低，不适合大型网站分布式场景

• 2PC

  • 2PC 即 Two-Phase Commit，二阶段提交

  • 2PC 分为两个阶段处理，阶段一：提交事务请求，阶段二：执行事务提交

  • 如果阶段一超时或者出现异常，2PC 阶段二中断事务

  • 阶段一：提交事务请求

    • 事务询问，协调者向所有参与者发送事务内容，询问是否可以执行提交操作，并开始等待各参与者进行响应
    • 执行事务，各参与者节点，执行事务操作，并将 undo 和 redo 操作计入本机事务日志；各参与者向协调者反馈事务问询的响应，成功执行返回 yes，否则返回 no
      
      

  • 阶段二：执行事务提交

    • 协调者在阶段二决定是否最终执行事务提交操作，这一阶段包含两种情形：
      • 情形一：执行事务提交，所有参与者 reply yes，那么执行事务提交
        • 发送提交请求，协调者向所有参与者发送 commit 请求
        • 事务提交，参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交操作之后，释放在整个事务执行期间占用的资源
        • 反馈事务提交结果，参与者在完成事务提交后，写协调者发送 ack 消息确认
        • 完成事务，协调者在收到所有参与者的 ack 后，完成事务
      • 情形二：中断事务，事情总会出现意外，当存在某一参与者向协调者发送 no 响应，或者等待超时，协调者只要无法收到所有参与者的 yes 响应，就会中断事务
        • 发送回滚请求，协调者向所有参与者发送 rollback 请求
        • 回滚，参与者收到请求后，利用本机 nndo 信息，执行 rollback 操作，并在回滚结束后释放该事务所占用的系统资源
        • 反馈回滚结果，参与者在完成回滚操作后，向协调者发送 ack 消息
        • 中断事务，协调者收到所有参与者的回滚 ack 消息后，完成事务中断
          
          

  • 2PC 解决的是分布式数据强一致性问题

    • 优点：实现原理简单
    • 缺点：
      • 性能问题：执行过程中间，节点都处于阻塞状态，各个操作数据库的节点此时都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局提交，参与者进行本地事务提交后才会释放资源，这样的过程会比较漫长，对性能影响比较大。
      • 协调者单点故障问题：事务协调者是整个 XA 模型的核心，一旦事务协调者节点挂掉，会导致参与者收不到提交或回滚的通知，从而导致参与者节点始终处于事务无法完成的中间状态
      • 丢失消息导致的数据不一致问题：在第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就会导致节点间数据的不一致问题

• 3PC
  • 针对 2PC 的缺点，研究者提出 3PC，即 Three-Phase Commit
  • 作为 2PC 的改进版，3PC 将原有的两阶段过程，重新划分为 canCommit、preCommit 和 doCommit 三个阶段
    • 阶段一：canCommit
      • 事务询问，协调者向所有参与者发送包含事务内容的 canCommit 的请求，询问是否可以执行事务提交，并等待应答
      • 各参与者反馈事务询问，正常情况下，如果参与者认为可以顺利执行事务，则返回yes，否则返回 no
        
        
    • 阶段二：preCommit
      • 在本阶段，协调者会根据上一阶段的反馈情况来决定是否可以执行事务的 preCommit 操作，有以下两种可能：
        • 执行事务预提交
          • 发送预提交请求，协调者向所有节点发出 preCommit 请求，并进入 prepared 阶段
        • 事务预提交
          • 参与者收到 preCommit 请求后，会执行事务操作，并将 undo 和 redo 日志写入本机事务日志
          • 各参与者成功执行事务操作，同时将反馈以 ack 响应形式发送给协调者，同时等待最终的 mommit 或 abort 指令
        • 中断事务
          • 加入任意一个参与者向协调者发送 no 响应，或者等待超时，协调者在没有得到所有参与者响应时，即可以中断事务：
            • 发送中断请求，协调者向所有参与者发送 abort 请求
            • 中断事务，无论是收到协调者的 abort 请求，还是等待协调者请求过程中出现超时，参与者都会中断事务
              
              
    • 阶段三：doCommit
      • 在这个阶段，会真正的进行事务提交，同样存在两种可能。
      • 执行提交
        • 发送提交请求，假如协调者收到了所有参与者的 ack 响应，那么将从预提交转换到提交状态，并向所有参与者，发送 doCommit 请求
        • 事务提交，参与者收到 doCommit 请求后，会正式执行事务提交操作，并在完成提交操作后释放占用资源
        • 反馈事务提交结果，参与者将在完成事务提交后，向协调者发送 ack 消息
        • 完成事务，协调者接收到所有参与者的 ack 消息后，完成事务
      • 中断事务
        • 在该阶段，假设正常状态的协调者接收到任一个参与者发送的 no 响应，或在超时时间内，仍旧没收到反馈消息，就会中断事务
        • 发送中断请求，协调者向所有的参与者发送 abort 请求
        • 事务回滚，参与者收到 abort 请求后，会利用阶段二中的 undo 消息执行事务回滚，并在完成回滚后释放占用资源
        • 反馈事务回滚结果，参与者在完成回滚后向协调者发送 ack 消息
        • 中端事务，协调者接收到所有参与者反馈的 ack 消息后，完成事务中断