Spring 事务传播机制

  • REQUIRED (必需的)

    如果当前有，则加入，合并成一个事务，没有则新建

  • REQUIRED_NEW (必需新建)

    新建，如果当前有事务，则当前事务挂起，父级异常不影响

  • SUPPORTS (支持)

    如果有，则加入，如果没有，则以非事务形式运行

  • NOT_SUPPORTED (不支持)

    以非事务形式运行，如果当前存在事务，当前事务挂起

  • NEVER (永不)

    以非事务形式运行，如果当前存在事务，抛异常

  • NESTED (嵌套)

    如果当前存在事务，成为父级事务的一个子事务，方法结束后不提交，只有等父事务结束才提交

    如果当前没有事务，则新建

    如果当前事务异常，父级可以捕获而不进行回滚，正常提交

    如果父级异常，当前事务回滚

  • MANDATORY (强制的)

    父级必须有事务，否则抛异常

事务的四个特性

  • Atomicity 原子性
  • Consistency 一致性
  • Isolation 隔离性
  • Duriablity 持久性

事务的隔离级别

  • Read Uncommitted 脏读
  • Read Committed 可重复读
  • Repeatable Read 幻读
  • Serializable

分布式事务

CAP 理论

Consistency 可用性 分区容错性 三则不可兼得，最多只能满足其中2条。ZK AP，Eureka 满足的是 CP。

BASE 理论

基本可用、软状态、最终一致性。

分布式事务解决方案

2PC 二阶段提交 ( Two-Phase Commit )

全局事务分成两阶段来处理，第一阶段进行准备工作，第二阶段确认是提交还是会滚，这个过程需要一个协调者和若干参与者。

  • 投票阶段 协调者询问各个参与者，是否可以提交，各参与者执行事务，写入 redo log 和 undo log，反馈相关信息。
  • 提交阶段 协调者发现所有参与者都可以提交事务，则给所有参与者发送commit 指令，通知提交。如果有任意一个参与者反馈失败，则通知所有参与者会滚。

存在的问题

  1. 阻塞问题，所有参与者都需要等待其他参与者的执行结果，暂用系统资源时间太长。
  2. 单点故障问题。参与者通知协调者成功后，节点崩溃，后续也无法收到协调者发送的commit消息。

TCC (Try , Commit , Cancel ) 补偿型事务

将事务分成三个方法

  • Try 准备阶段 资源检查和预留
  • Commit 提交阶段
  • Cancel 回滚阶段

整个过程同样分为两个阶段，第一步准备，第二步执行。

优点

  1. 不会全局阻塞，每个阶段执行完毕都会释放锁，不需要等待其他事务。

缺点

  1. 代码侵入性强，比较繁琐。开发成本高，每个事务都需要实现3个步骤。
  2. 安全性问题，cancel 阶段如果失败无法释放锁，需要重试等问题。

SEGA 模式

  • 长事务的实现，每一个参与者提供一个冲正补偿服务，用户根据业务场景实现正向操作和逆向操作。

可靠消息服务

  • 使用消息中间件实现

常用的模式

  • AT ( TCC 原理的优化 )
  • SEGA
  • XA

Q.E.D.