别等生产出事故才想起回滚：一次数据一致性演练，到底该测什么？

作者：Echo_Wish

做运维这些年，我越来越觉得一件事：系统真正的可靠，不是永远不出错，而是出了错以后，你知道哪里出了问题、哪些数据受到了影响，以及怎样把它安全地恢复回来。

平时我们做系统测试，最常见的场景是什么？

接口请求成功，返回 HTTP 200；数据库插入成功，查询也正常；服务重启之后，一切看起来都没问题。测试人员点点头，开发人员提交代码，运维人员发布上线。

大家都觉得挺好。

可问题是，生产环境里的事故，往往不发生在一切正常的时候，而是发生在那些我们觉得“不太可能”的边界上。

比如，一个订单已经写入数据库，但是调用下游系统时网络突然断了；比如，库存已经扣减成功，服务却在返回响应之前崩溃了；再比如，一批数据同步到一半，任务进程被强制终止，重启后又把前面成功的数据执行了一遍。

这时候，你会发现一个特别现实的问题：

接口成功，不代表业务成功；数据库有数据，不代表数据一致；能够回滚，也不代表回滚之后就是正确的。

所以，今天不聊那些听起来很高大上的分布式理论，我们就从日常运维和开发的实际场景出发，聊聊数据一致性事故演练：边界怎么测，故障怎么造，回滚路径怎么设计，以及怎样判断一次演练到底有没有价值。

一、别只测正常流程，真正的坑都藏在边界里

先看一个特别常见的业务场景：订单系统需要扣减库存。

正常流程很简单：

1. 接收订单请求。
2. 扣减库存。
3. 保存订单。
4. 返回处理成功。

如果所有操作都顺顺利利，当然没有问题。

但我们做测试时，不能只验证这条正常路径。因为生产环境不是一台永远稳定的测试机器，网络超时、进程退出、数据库死锁、消息重复投递，这些情况随时可能出现。

举个例子，假设库存原来有 10 件，用户购买了 2 件。

库存扣减成功，变成 8 件。可就在系统准备返回成功响应时，应用突然崩溃了。

用户没有收到成功提示，以为订单失败，于是重新提交一次。

如果系统没有幂等控制，库存可能再次变成 6 件。

用户明明只买了 2 件，库存却扣减了 4 件。

这就是典型的业务数据不一致。

问题出在哪里？不是数据库不会执行 SQL，也不是服务器性能不够，而是系统没有正确处理“操作已经成功，但调用方不知道”的情况。

我一直认为，测试的价值不只是证明代码能跑通，更重要的是证明代码在不正常的情况下仍然守得住业务规则。

因此，一次数据一致性演练，至少应该覆盖下面这些边界。

注意，这里有一个很容易被忽略的地方：故障不能只发生在操作开始之前，也要发生在操作成功之后、结果返回之前。

因为很多真正麻烦的事故，恰恰发生在这段时间里。

二、用代码制造故障，而不是靠运气等事故

如果我们想验证订单处理的可靠性，就不能只在测试环境里反复点击按钮，然后祈祷系统偶尔出错。

更好的办法是，主动设计故障注入点。

例如，在测试环境中，我们可以用一个简单的参数，控制程序在库存扣减之后模拟异常。

def create_order(order_id, product_id, quantity, fail_after_deduct=False):    deduct_inventory(product_id, quantity)    # 测试环境故障注入：    # 模拟库存已扣减，但订单创建失败    if fail_after_deduct:        raise RuntimeError("模拟故障：库存扣减后发生异常")    save_order(order_id, product_id, quantity)

运行这段代码时，如果 fail_after_deduct=True，库存扣减可能已经完成，订单却没有保存。

这段代码的价值不在于模拟了一个异常，而在于它暴露了一个设计问题：库存和订单之间的操作没有形成可靠的整体。

如果库存扣减发生在独立事务中，那么后续订单创建失败时，数据库无法自动替你撤销之前的扣减。

当然，实际项目不能简单地把所有操作都包进一个事务就认为万事大吉。我们需要先明确：这些数据是否在同一个数据库中？是否跨越多个服务？是否涉及消息队列或外部接口？

如果订单和库存都在同一个关系型数据库中，且业务允许在同一个事务内完成，那么可以考虑下面这种方式。

def create_order(conn, order_id, product_id, quantity):    try:        conn.begin()        deduct_inventory(            conn,            product_id,            quantity        )        save_order(            conn,            order_id,            product_id,            quantity        )        conn.commit()    except Exception:        conn.rollback()        raise

这里的 begin()、commit() 和 rollback() 是示意代码，具体方法取决于数据库驱动。

核心思想很简单：库存扣减成功、订单创建失败时，不允许只留下其中一部分已经提交的数据。

但请注意，事务回滚也有自己的边界。

如果库存已经提交，而系统随后调用了一个外部支付接口，那么数据库事务并不能撤销已经发生的支付。类似地，邮件已经发送、第三方接口已经执行的操作，也不会因为本地事务回滚而自动消失。

所以，回滚不是万能后悔药，它只能撤销自己真正能够控制的那部分操作。

这也是为什么我们要把故障注入点设计得足够细，而不是简单地测试一次“数据库报错”。

三、最值得测的四个时间点，别漏了

在我看来，数据一致性演练最重要的工作之一，就是把业务操作拆成几个关键时间点，然后逐个验证。

以订单写入数据库并通知下游系统为例，可以设计四组测试。

1. 写入之前失败

数据库连接失败，订单根本没有写进去。

这个场景通常比较容易处理：返回失败，不发送下游通知，允许安全重试。

但是要检查一点：失败时有没有提前修改缓存、扣减其他资源，或者写入外部系统。

不要因为数据库没数据，就想当然地认为整个业务没有产生副作用。

2. 写入成功，提交之前失败

假设订单和库存操作处于同一个事务中，在执行过程中发生异常。

我们要验证：

• 订单记录是否没有被提交。
• 库存是否恢复到原值。
• 相关明细表是否没有留下孤立记录。
• 连接释放后，其他请求是否能够正常执行。

这个场景主要验证事务边界是否正确。

3. 数据提交成功，通知下游之前失败

订单已经成功写入数据库，但应用还没有通知 ERP、WMS 或其他下游系统，进程就退出了。

这时候，数据库事务已经无法帮你解决全部问题。

如果业务要求最终通知下游，就需要考虑可靠的事件记录机制。例如，在同一个数据库事务中，同时保存业务数据和一条待发送事件，再由后台任务负责投递。

BEGIN TRANSACTION;

INSERT INTO Orders
    (OrderId, Status)
VALUES
    (@OrderId, 'Created');

INSERT INTO OutboxEvents
    (EventId, BusinessId, EventType, Status)
VALUES
    (@EventId, @OrderId, 'OrderCreated', 'Pending');

COMMIT TRANSACTION;

这里的关键是：订单数据和待发送事件一起提交。

即使应用在提交之后突然退出，后台任务仍然可以根据 Pending 状态找到尚未发送的事件。

这种模式通常称为 Outbox 模式。它不能保证消息只发送一次，但可以帮助我们可靠地记录待发送的业务事件。下游仍然需要幂等处理，因为消息可能重复投递。

4. 下游处理成功，但本地不知道结果

这个场景最容易制造事故。

比如 MES 向 ERP 发送一张采购单，ERP 已经成功接收并创建记录，但响应数据在网络传输过程中丢失了。

MES 看到超时，就重新发送。

如果 ERP 每次收到请求都会新建一张单据，那么一张采购单可能就变成两张。

解决思路不是简单地禁止重试，而是给业务请求设计稳定的幂等标识。

def process_request(request):    request_id = request["request_id"]    existing = find_result_by_request_id(request_id)    if existing is not None:        return existing    return execute_business_operation(request)

这段代码只能表达基本思路，不能直接作为并发安全的生产实现。两个相同请求可能同时查询，都发现记录不存在，然后各自执行一次。

真正的实现还需要数据库唯一约束、事务控制，以及对重复键冲突的正确处理。对于外部系统，还需要对方支持幂等键，或者提供可查询的业务单号。

记住一句话：

超时不等于失败，重试也不等于安全。

如果系统没有办法确认上一次操作的真实结果，那么重试之前就必须有一套明确的判定机制。

四、回滚路径不能只写一句 rollback()

很多系统的异常处理代码里，都能看到这样一段逻辑：

try:    execute_business()except Exception:    rollback()    raise

从代码规范上说，这没什么问题。但从事故演练的角度看，这远远不够。

因为我们还不知道三个关键问题：

第一，execute_business() 到底执行到了哪一步？

第二，rollback() 是否真的成功？

第三，如果回滚本身失败了，下一步怎么办？

真正可用的回滚方案，应该能够回答这些问题。

对于数据库内部的事务，可以依靠数据库事务机制撤销尚未提交的修改。但对于已经提交的数据、已发送的消息、已完成的外部操作，就必须考虑补偿、重放或者人工恢复。

例如，一次库存调整可能需要记录原始数量、调整数量、业务单号和操作原因。发生事故时，不能简单地再执行一次反向 SQL，而应该先确认当前库存、原始流水和后续业务是否已经发生变化。

否则，原本想修复一次扣减错误，最后却可能把其他正常出库的结果也一起抵消。

我建议把回滚路径分成三个层次。

第一层：自动回滚。

适用于尚未提交的数据库事务，或者能够安全撤销的局部操作。重点验证回滚后数据是否恢复到事务开始前的状态。

第二层：业务补偿。

适用于无法通过数据库事务直接撤销的操作。比如，订单已经创建，需要通过取消订单的业务流程进行补偿。补偿不是把历史记录删除，而是通过新的、可追溯的业务操作纠正状态。

第三层：人工恢复。

当自动回滚和业务补偿都无法安全完成时，系统应当保留错误现场、明确受影响的数据范围，并提供可执行的恢复步骤。

这三个层次不是互相替代的关系，而是为不同类型的故障准备不同的处理办法。

更重要的是，回滚路径也必须接受故障注入。

如果补偿操作执行到一半再次失败，系统能否识别当前进度？下一次恢复能否从未完成的步骤继续？会不会把已经补偿成功的部分再次执行？

这些问题如果没有在演练中验证过，生产事故发生时，所谓的回滚方案可能只是一份看起来很完整的文档。

五、怎么判断数据真的一致了？不要只看接口返回值

做完故障演练，最容易出现的一种情况就是：接口返回了预期的错误，日志也打印了异常，大家就觉得测试通过了。

但真正应该验证的是业务不变量。

所谓业务不变量，就是无论系统经历正常操作、异常中断还是恢复过程，都必须满足的业务规则。

例如：

• 库存不能小于零，除非业务明确允许负库存。
• 同一个业务请求不能产生两笔有效的重复订单。
• 已完成的业务不能无故退回到未处理状态。
• 订单明细与订单主表之间不能出现不符合规则的孤立记录。
• 成功提交的业务事件最终应当被处理，或者进入明确的失败状态。
• 同一个业务单据在 MES 和 ERP 之间，必须能够通过稳定的业务标识进行核对。

这些规则比单纯检查 HTTP 状态码更有意义。

举个例子，我们可以使用 SQL 检查订单和明细之间是否存在不符合业务规则的记录：

SELECT
    o.OrderId
FROM Orders o
LEFT JOIN OrderDetails d
    ON d.OrderId = o.OrderId
WHERE d.OrderId IS NULL
  AND o.Status = 'Created';

这条 SQL 只是一个示例，实际业务中必须确认“已创建订单不允许没有明细”这一规则确实成立。

如果业务允许空明细订单，那么查询结果就不一定代表事故。

这恰恰说明了一件事：数据一致性检查不能脱离业务规则，否则你可能把正常数据当成异常，也可能把真正的异常漏掉。

对于跨系统同步，最好进一步建立核对机制。

例如，每天对账时比较 MES 和 ERP 的业务单号、处理状态、关键数量以及更新时间。发现差异后，先定位差异原因，再决定补发、补偿还是人工处理，而不是看到数据不一致就直接覆盖其中一边。

尤其要注意，不能只比总记录数。

两个系统各有 1000 条记录，并不代表它们保存的是同一批业务数据。真正有效的核对，需要关注业务主键、关键字段、状态流转以及缺失和重复记录。

六、批量任务最怕半途而废，更怕重跑

除了接口，批量同步任务也是数据一致性事故的高发区。

假设每天凌晨有一个任务，需要把 10 万条 MES 业务记录同步到 ERP。任务运行到第 6 万条时，服务器重启了。

第二天任务重新执行，会发生什么？

如果它从头开始跑，并且没有幂等控制，那么前面已经成功的 6 万条数据就可能被重复处理。

如果它直接从第 6 万条继续，又可能因为前面的部分操作没有真正成功，而漏掉某些数据。

所以，批量任务的演练重点，不是单纯验证任务能不能启动，而是验证它在任意位置中断之后，是否仍然能够安全恢复。

一个比较实用的思路，是为每条业务记录维护明确的处理状态。

例如：

UPDATE SyncTasks
SET Status = 'Processing',
    AttemptCount = AttemptCount + 1,
    UpdatedAt = GETDATE()
WHERE TaskId = @TaskId
  AND Status IN ('Pending', 'Retry');

这里需要注意，实际任务认领逻辑还应该考虑并发执行、超时任务回收和状态迁移规则。仅靠这条更新语句，并不能自动解决所有竞争条件。

我们还需要明确区分以下状态：

• 待处理：尚未开始。
• 处理中：已经被任务认领。
• 成功：已经确认下游处理完成。
• 待重试：失败后允许再次执行。
• 待人工处理：自动恢复无法安全完成。

如果下游已经处理成功，但本地更新状态之前发生故障，那么任务重启后仍然可能再次发送请求。因此，状态管理必须与幂等处理配合使用，而不是只增加一个 Status 字段就结束了。

还有一点经常被忽略：任务认领后，如果进程突然退出，记录可能长期停留在“处理中”。

所以，系统还应该有合理的超时判断机制，并在回收任务时重新核实下游结果。不能只因为一条任务超时，就认定它从未执行成功。

一个合格的批量任务，不仅要能处理数据，还要能够解释每一条数据处理到了哪里，以及下一步为什么可以安全执行。

七、给自己设计一套真正能落地的演练流程

讲了这么多，最后还是要回到实际工作。

如果明天就要给一个 MES 与 ERP 的数据同步接口做一致性演练，我不会一上来就设计特别复杂的测试平台，而是先把下面几件事做好。

数据一致性演练检查清单

完成进度

0/6

明确业务规则

定义唯一业务标识、状态流转、数量约束和允许的重复行为。

建立测试基线

记录演练前的业务数据、关键数量、流水记录和下游状态。

逐点注入故障

覆盖写入前、事务中、提交后、下游成功但响应丢失等场景。

验证重试与回滚

检查是否重复执行、是否留下半成品，以及补偿失败后能否恢复。

执行数据核对

通过 SQL、业务流水和上下游对账确认最终状态，而不只看接口响应。

保存演练证据

记录故障时间、影响范围、日志、恢复步骤、耗时和遗留问题。

还有一个非常重要的前提：故障演练必须在经过授权、能够控制影响范围的环境中进行。生产环境演练尤其要有明确的审批、流量隔离、数据备份、停止条件和应急联系人。

不要为了验证回滚能力，就直接在生产数据库里删除数据、杀进程，或者随意断开关键服务。

如果测试环境与生产环境的数据结构、事务配置和部署方式差别很大，那么测试结果也不能完全代表生产表现。我们要尽可能还原关键条件，同时控制演练风险。

演练结束后，别只写一句“测试通过”。

更有价值的结论应该是：我们在哪个时间点注入了什么故障，影响了哪些数据，系统采取了什么处理方式，最终数据是否满足业务规则，以及还有哪些场景没有覆盖。

这才是一份真正能帮助团队减少事故的演练记录。

写在最后

我始终觉得，运维工作的价值，不只是让服务器一直在线，也不是让监控大屏永远保持绿色。

真正重要的是，当一个接口超时、一个数据库连接断开、一个批量任务突然退出时，我们能不能清楚地知道系统发生了什么，哪些业务已经成功，哪些操作需要重试，以及怎样恢复才不会制造第二次事故。

很多数据一致性问题，表面上看是某条 SQL 写错了，或者某个接口偶尔超时，往深处看，却是系统没有定义清楚失败之后应该怎么办。

正常流程大家都会写，异常处理大家也都会写。真正拉开差距的，是能不能把那些不太好看的场景提前想清楚，再通过演练证明自己的判断是对的。

不要把回滚当成事故发生后的补救措施，而要把它当成系统设计时就必须验证的一项能力。

下次上线之前，不妨多问自己三个问题：

第一，如果操作执行到一半，服务器突然没了，会留下什么？

第二，如果下游已经成功，但我没有收到响应，重新执行会发生什么？

第三，如果第一次恢复失败了，我还有没有第二条路？

这三个问题看起来很普通，却可能决定一次小故障究竟是几分钟就能处理完，还是最终演变成需要多个团队通宵排查的数据事故。

毕竟，真正靠谱的系统，不是因为它从来没有失败过，而是因为我们早就认真考虑过：万一失败了，该怎么办。