数据库快照隔离级别下写偏斜异常处理

数据库快照隔离级别（Snapshot Isolation，SI）下的写偏斜（Write Skew）异常，是并发控制领域一个非常经典且容易被忽视的问题。简单来说，写偏斜发生在两个事务各自读取数据库的快照，然后基于各自看到的数据独立做出写入决策，最终导致违反了某个全局约束条件。比如医院排班系统中，要求至少有一名医生值班，两个事务同时看到"有一名医生在值班"，于是各自把自己负责的医生状态改为"下班"，结果造成无人值班的违规状态。快照隔离能解决脏读、不可重复读和幻读，但它解决不了写偏斜，因为每个事务操作的是自己看到的快照版本，彼此互不感知对方的写入。

要彻底理解和处理这个问题，我们需要从写偏斜的本质机制、具体场景、检测手段以及工程实践中的解决方案四个维度来展开。下面我会逐一拆解，给出可落地的方案。

一、写偏斜异常的本质机制

写偏斜属于"幻读"类异常的一种变体，但它比传统幻读更隐蔽。传统幻读是一个事务两次查询结果不同，而写偏斜是两个事务在同一个快照上各自做了看似合理的操作，合在一起却破坏了约束。核心原因在于：快照隔离保证的是"每个事务看到的是某个时间点的一致视图"，但它不保证"多个事务的写入组合后仍然满足业务约束"。

从并发控制理论来看，快照隔离实现的是多版本并发控制（MVCC），每个事务在开始时获取一个快照时间戳，所有读操作都基于这个时间戳对应的数据版本。写操作时，如果目标数据行的版本比事务快照新，则事务会被回滚（即"首次提交者赢"策略）。但问题在于，写偏斜场景下，两个事务读取的是不同的数据行（或同一行的不同逻辑判断），它们的写操作目标可能不冲突，因此不会触发回滚。

举一个更直观的例子：数据库中有一张账户表，约束是"所有账户余额之和必须大于等于1000"。事务A看到余额总和是1200，于是从账户X转出300；事务B也看到余额总和是1200（因为它的快照在A提交之前），于是从账户Y转出400。两个事务都成功提交，最终余额总和变成500，约束被破坏。这就是典型的写偏斜。

二、写偏斜的典型业务场景

写偏斜不是理论上的极端情况，它在真实业务系统中频繁出现。以下是几个最常见的场景：

场景一：排班与资源分配系统。如前所述，医院、工厂、客服中心等需要保证最少在岗人数。两个排班员同时操作，各自把自己负责的人员标记为"休息"，最终在岗人数不足。这种场景在任何需要"至少N个"约束的系统中都会出现。

场景二：库存与订单系统。假设仓库有100件商品，两个订单事务同时读取到库存为100，各自下单购买80件。如果系统允许两个事务都通过（因为它们读的是同一个快照，且写的是不同的扣减记录），最终库存会变成负数。虽然有些系统用行锁来防止，但在快照隔离下如果锁粒度不够，仍然可能出问题。

场景三：金融账户与风控系统。多个风控规则检查事务同时读取账户状态，各自判断"风险可控"并批准操作，合在一起可能导致风险敞口超标。这种场景在微服务架构下尤其危险，因为不同服务可能使用不同的数据库连接和事务。

三、写偏斜的检测与诊断方法

处理问题的前提是发现问题。写偏斜异常因为不会抛出错误、不会导致死锁，往往在生产环境中默默发生，直到业务数据出现逻辑矛盾才被发现。以下是几种有效的检测手段：

1. 约束触发器（Constraint Triggers）。在数据库层面设置约束检查触发器，在事务提交前验证全局约束是否满足。例如在PostgreSQL中可以使用deferrable约束配合触发器来实现。但需要注意，触发器本身也有性能开销，且在高并发下可能成为瓶颈。

2. 应用层二次校验。在事务提交前，应用程序重新读取最新数据，验证业务约束。这种方式简单但不可靠，因为在重新读取和提交之间仍然存在竞态窗口。

3. 专用测试工具。使用如Jepsen这样的分布式系统测试框架，模拟并发场景，专门检测快照隔离下的写偏斜。这是目前业界公认最有效的检测方式之一，很多数据库厂商在发布新版本前都会用Jepsen进行回归测试。

-- PostgreSQL中使用可延迟约束检测写偏斜的示例
BEGIN;
SET CONSTRAINTS ALL DEFERRED;
-- 事务A：检查当前值班医生数
SELECT COUNT(*) FROM doctors WHERE on_duty = true;
-- 如果 >= 1，则将某医生设为下班
UPDATE doctors SET on_duty = false WHERE id = 101;
COMMIT;
-- 约束在COMMIT时检查，如果违反则回滚

四、工程实践中的解决方案

针对写偏斜，业界有多种解决思路，从数据库层面到应用层面都有对应方案。下面按推荐优先级排列：

方案一：升级到可串行化隔离级别（Serializable）。这是最彻底的解决方式。PostgreSQL和SQL Server都支持可串行化隔离级别，它能保证事务的执行效果等同于某种串行执行顺序，从根本上消除写偏斜。PostgreSQL的可串行化隔离使用SSI（Serializable Snapshot Isolation）技术，通过检测事务之间的依赖关系来判断是否存在危险结构，如果检测到则回滚其中一个事务。

-- PostgreSQL中设置可串行化隔离级别
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT * FROM accounts WHERE id = 1;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
COMMIT;

可串行化的代价是可能增加事务回滚率，在高冲突场景下性能会有所下降。但对于写偏斜高发的业务，这是最值得投入的方案。

方案二：显式加锁（SELECT FOR UPDATE / SELECT FOR SHARE）。在快照隔离的基础上，对关键数据行加排他锁或共享锁，强制事务之间产生等待关系。这种方式相当于在MVCC之上叠加了悲观锁机制。

-- 使用SELECT FOR UPDATE防止写偏斜
BEGIN;
SELECT * FROM doctors WHERE on_duty = true FOR UPDATE;
-- 此时其他事务如果也执行FOR UPDATE会被阻塞
UPDATE doctors SET on_duty = false WHERE id = 101;
COMMIT;

这种方法的优点是精确控制锁范围，缺点是需要开发者准确识别哪些数据需要加锁，遗漏就会出问题。而且锁的粒度选择不当会影响并发性能。

方案三：应用层乐观校验 + 重试机制。在事务提交前，应用层重新检查约束条件，如果发现违反则回滚并重试。这种方式适合冲突概率不高的场景，代码实现相对简单。

-- 应用层伪代码示例
function transfer(from_id, to_id, amount) {
    for (retry = 0; retry < MAX_RETRIES; retry++) {
        begin_transaction();
        from_account = SELECT balance FROM accounts WHERE id = from_id;
        to_account = SELECT balance FROM accounts WHERE id = to_id;
        if (from_account.balance < amount) {
            rollback();
            throw InsufficientFunds();
        }
        // 二次校验：重新读取最新余额
        latest_from = SELECT balance FROM accounts WHERE id = from_id;
        if (latest_from.balance < amount) {
            rollback();
            continue; // 重试
        }
        UPDATE accounts SET balance = balance - amount WHERE id = from_id;
        UPDATE accounts SET balance = balance + amount WHERE id = to_id;
        commit();
        return;
    }
    throw MaxRetriesExceeded();
}

方案四：使用物化视图或汇总表进行预校验。对于"总和约束"类的写偏斜，可以维护一个物化视图或汇总表，在写入前先检查汇总值是否满足条件。这种方式将约束检查从跨行查询变成单行查询，性能更好，但需要额外的维护成本来保证汇总数据的一致性。

方案五：数据库原生的约束机制。某些数据库支持声明式的跨行约束。例如PostgreSQL支持EXCLUDE约束和CHECK约束（虽然CHECK约束目前不支持子查询，但可以通过触发器模拟）。SQL Server的Filtered Index配合约束也能在一定程度上防范写偏斜。

五、不同数据库的支持情况对比

不同数据库对写偏斜的处理能力差异很大，选型时需要重点关注：

PostgreSQL：支持真正的可串行化隔离（SSI），是目前对写偏斜防护最完善的开源数据库。快照隔离（Repeatable Read级别实际上就是SI）下会出现写偏斜，但升级到Serializable即可解决。推荐生产环境中对关键业务使用Serializable。

SQL Server：快照隔离（通过ALLOW_SNAPSHOT_ISOLATION开启）下同样存在写偏斜。SQL Server的Serializable级别使用锁机制而非SSI，性能开销较大但能解决问题。另外SQL Server 2019引入了MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT，对内存优化表有更好的隔离支持。

MySQL/InnoDB：默认的Repeatable Read级别通过间隙锁和临键锁在一定程度上防止了部分写偏斜，但不是完全可靠。MySQL 8.0引入了更好的MVCC实现，但快照隔离（通过设置transaction_isolation='READ-COMMITTED'配合某些配置）下仍需注意。MySQL目前没有原生的可串行化快照隔离实现。

Oracle：Oracle的Serializable级别使用传统的锁机制，而Read Committed（默认）和Serializable之间没有快照隔离的中间选项。Oracle通过SELECT FOR UPDATE和应用层逻辑来防范写偏斜。

六、最佳实践建议

在实际项目中，我的建议是分层防御：首先评估业务场景中写偏斜的风险等级，对于金融、医疗、库存等强约束场景，直接使用可串行化隔离；对于一般业务，在关键操作上使用SELECT FOR UPDATE显式加锁；同时在应用层加入约束校验和重试逻辑作为兜底。不要依赖单一手段，因为任何一种方案都有其边界条件。

另外，团队需要建立对隔离级别的统一认知。很多开发者只知道"读已提交"和"可重复读"，对快照隔离和可串行化的区别缺乏了解。建议在技术规范中明确规定：哪些表、哪些操作必须使用什么隔离级别，避免开发人员随意选择导致隐患。

最后要强调一点：写偏斜不是"小概率事件"。在高并发系统中，只要存在多事务并发读写同一组受约束数据的场景，写偏斜就一定会发生，只是时间早晚的问题。与其事后修复数据，不如事前做好隔离级别的选型和约束防护。这是数据库架构设计中必须认真对待的一环。

数据库快照隔离级别下写偏斜异常处理

服务指南

帮助中心