事务四大特性（ACID）、四大隔离级别、Spring 七大事务传播行为

事务是数据库保证数据安全、可靠、一致的核心机制也是后端开发与运维必须掌握的基础核心知识点。一、事务四大特性ACID事务是一组不可分割的数据库操作序列要么全部执行成功要么全部执行失败。四大特性是事务的基石分别保证操作、数据、并发、持久化层面的可靠性。1.1 原子性Atomicity定义事务是最小执行单元内部所有 SQL 操作不可分割必须同时成功或同时失败回滚。为什么需要原子性避免业务操作执行一半导致数据错乱。场景银行转账账户 A 扣除 100 元、账户 B 增加 100 元两步操作。若扣款成功、加款失败资金将凭空消失原子性可杜绝此类问题。实现机制依靠 Undo Log 回滚日志实现。执行修改前记录数据旧值事务异常或回滚时根据 Undo Log 恢复原始数据保证事务执行前后状态一致。1.2 一致性Consistency定义事务执行前后数据库的完整性约束、业务规则始终合法数据从一个合法状态迁移到另一个合法状态。为什么需要一致性保证数据永远符合业务逻辑不出现非法数据。典型场景商品库存不能为负数、订单金额必须与明细总和一致、主键与唯一索引不可冲突等。实现机制依靠数据库约束包括主键、外键、唯一键、非空约束由原子性、隔离性、持久性共同保障同时配合应用层业务逻辑校验。 一致性是事务的最终目标原子性、隔离性、持久性是实现一致性的手段。1.3 隔离性Isolation定义多个并发事务同时执行时相互隔离、互不干扰一个事务不会看到另一个事务未提交的中间状态。为什么需要隔离性高并发场景下多事务同时读写同一数据会导致数据混乱出现脏读、不可重复读、幻读等问题隔离性用于避免这类异常。 实现机制 通过锁机制实现包括行锁、表锁、间隙锁依托 MVCC 多版本并发控制实现读不加锁、读写不冲突并通过事务隔离级别平衡并发性能与数据安全。1.4 持久性Durability定义事务一旦提交成功对数据的修改将永久保存数据库宕机、重启也不会丢失。为什么需要持久性 保证已确认的业务结果不可逆如支付成功、订单创建等操作结果不可丢失。实现机制依靠 Redo Log 重做日志与 WAL 预写日志机制实现。先顺序写日志再随机写数据文件数据库崩溃重启后通过 Redo Log 恢复已提交数据保证提交操作永久生效。二、事务四大隔离级别并发事务会带来脏读、不可重复读、幻读三大问题。按问题严重程度脏读 不可重复读 幻读数据库通过隔离级别控制并发可见性级别越高越安全但并发性能越低。2.1 并发三大异常问题1脏读Dirty Read一个事务读到另一个事务未提交的数据若对方回滚该数据即为脏数据。例如 T1 修改库存为 90 未提交T2 读到 90随后 T1 回滚库存恢复 100T2 读到无效值。危害是业务基于错误数据执行逻辑导致数据错误。2不可重复读Non-repeatable Read同一事务内多次读取同一行数据结果不一致中间被其他事务修改并提交。例如 T1 第一次查询余额为 100T2 修改为 80 并提交T1 再次查询结果变为 80。 该问题主要针对 update、delete 操作。3幻读Phantom Read同一事务内两次范围查询结果条数不一致其他事务插入或删除数据并提交。例如 T1 查询余额大于 50 的记录共 1 条T2 插入一条新数据并提交T1 再次查询结果变为 2 条。 该问题主要针对 insert 操作。2.2 四大隔离级别详解1读未提交Read Uncommitted这是最低隔离级别允许事务读取其他事务未提交的数据。 脏读、不可重复读、幻读三类问题均存在。 性能最高但数据完全不可控生产环境几乎不使用。2读已提交Read Committed, RC事务只能读取到其他事务已经提交的数据解决了脏读问题但仍存在不可重复读和幻读。 该级别为 Oracle、SQL Server 默认隔离级别实现方式为语句级快照每次查询都会生成新的数据版本。3可重复读Repeatable Read, RR事务启动时生成全局数据快照整个事务期间多次读取同一数据结果保持一致解决了脏读和不可重复读问题理论上仍存在幻读。 MySQL InnoDB 默认使用该级别通过 MVCC 加间隙锁的组合在实际业务场景中基本规避了幻读。 与 RC 的核心区别是RC 每次查询生成新快照RR 仅在事务启动时生成一次快照全程使用同一版本。4串行化Serializable最高隔离级别事务排队串行执行读写相互阻塞完全避免脏读、不可重复读、幻读所有问题。 数据安全性最高但并发性能极低仅用于金融、账务等对一致性要求极高且并发量小的核心场景。三、Spring 事务七大传播行为事务传播行为用于多个带事务方法相互调用时定义事务如何传递、合并、新建、挂起是业务层事务控制的核心。传播行为主要解决三个问题被调用方法是否需要事务已有事务时是加入、新建还是挂起内外事务是否独立、回滚是否相互影响。3.1 REQUIRED必需的默认最常用规则为当前无事务则新建有事务则加入。回滚机制为内外事务一体任意异常全部回滚。 适用于下单、支付、扣库存等强一致性业务。例如创建订单、扣库存、记录日志的流程必须同时成功或同时失败。3.2 SUPPORTS支持的规则为有事务则加入无事务则以非事务方式运行。特点是不强制事务性能更高。 适用于查询操作、列表获取、数据统计等对事务无强要求的场景。3.3 MANDATORY强制的规则为强制要求必须在已有事务内执行无事务直接抛异常。 作用是防止核心逻辑被无事务调用避免数据风险。 适用于核心扣款、库存扣减等关键子方法。3.4 REQUIRES_NEW需要新建规则为无论外部是否有事务都新建独立事务。回滚机制为内外事务完全隔离外层回滚不影响内层提交。 适用于操作日志、消息发送、计费记录等需要独立留存的场景。 例如下单失败主流程回滚但下单失败的日志必须保留。3.5 NOT_SUPPORTED不支持的规则为始终以非事务方式执行若外部存在事务则将其挂起。 特点是无回滚、无锁、性能极高。 适用于大批量数据导入、导出、文件同步等长耗时、无强一致性要求的操作。3.6 NEVER从不规则为强制要求在无事务环境下运行若检测到当前存在事务直接抛异常。 适用于严禁在事务中执行的长耗时操作避免长事务持有锁导致锁等待、系统卡顿。3.7 NESTED嵌套的规则为作为外层事务的子事务存在拥有独立保存点 savepoint。 回滚机制为内层异常可仅回滚子事务不影响外层外层异常则内层必须回滚。 适用于复杂流程、多步骤审批、子任务需要局部容错的场景。