数据库存：架构师一页讲清：数据校验与保证扣减一致性的关系

库存明明已经做了“库存是否充足”的校验，高并发下却仍然可能出现超卖、重复扣减，甚至订单成功而库存没有减少。问题通常不在校验条件写错，而在于“校验通过”与“真正扣减”之间存在一个并发时间窗口。数据校验负责判断请求是否合理，数据库原子更新负责让扣减动作成立，事务负责组合多个操作，幂等负责拦截重复请求，补偿机制则负责处理跨系统失败。把这些职责混为一谈，是扣减一致性问题长期反复出现的根源。

本文不把“校验、事务、锁、幂等”简单罗列成技术名词，而是从一次库存扣减到底经历了什么开始，拆解每个机制能保证什么、不能保证什么，以及在单库、缓存、消息队列和微服务场景下应该如何取舍。

一、先给结论：数据校验不是一致性保障的终点

1. 校验回答的是“现在能不能扣”

数据校验的本质，是在某个时间点读取数据，并根据业务规则判断请求是否合法。例如，购买数量必须大于零，商品必须处于可售状态，账户余额必须足够，优惠券必须尚未使用。

这些判断非常必要，但它们描述的只是读取瞬间的事实。库存为 10，表示某一刻数据库中可用库存是 10；它并不意味着在当前请求完成更新之前，其他请求不会先消耗这 10 件库存。

因此，下面这句话只能说明前置条件成立：

“本次读取时，库存大于或等于购买数量。”

它不能直接推出下面这句话：

“本次请求一定能够安全完成扣减。”

2. 一致性回答的是“并发和失败后是否仍然正确”

扣减一致性关注的不是一次请求能否通过判断，而是多个请求同时到达、请求超时重试、服务中途崩溃、消息重复投递、缓存延迟和跨服务调用失败后，系统最终状态是否符合业务事实。

以库存为例，一致性至少包含几个层次：

• 库存不能因为并发扣减而小于业务允许的下限；
• 同一个业务请求不能被重复扣减；
• 扣减成功后，订单或扣减流水不能无故丢失；
• 扣减失败时，不能留下“订单成功但库存已扣”的错误状态；
• 缓存、消息和数据库之间出现短暂差异时，最终能够收敛或被修复。

3. 五个机制应当各司其职

在实际设计中，我通常用下面这张职责地图判断方案是否完整：

最容易记住的一句话是：校验负责判断，原子更新负责扣减，事务负责组合，幂等负责去重，补偿负责恢复。

二、真实场景：为什么“先查库存再扣减”会出错

1. 一个库存为 1 的最小案例

为了看清问题，不需要先讨论复杂的分布式事务。假设某个商品只剩 1 件，同时有两个用户提交购买请求，每个请求购买 1 件。应用代码大致如下：

库存 = SELECT available FROM stock WHERE sku_id = 1001;
if (库存 >= 1) {

UPDATE stock

SET available = available - 1

WHERE sku_id = 1001;

}

在低并发环境下，这段代码经常表现正常，所以问题很容易被忽略。真正的风险出现在两个请求的执行时间交错时。

这里真正的问题不是“有没有做库存校验”，而是两个请求都基于同一个旧库存值做出了决定。校验本身没有错，错的是校验结果被当成了后续更新的永久依据。

2. 数据库隔离级别不会自动修复错误业务流程

有些团队遇到这个问题时，会直接提高事务隔离级别，甚至把所有查询都改成加锁查询。这样有时能够缓解问题，但不能把它当成万能修复方案。

如果业务仍然是“先查、应用层判断、再更新”，那么设计者必须明确以下问题：

• 查询和更新是否处在同一个事务中；
• 查询使用的是普通读还是当前读；
• 锁是否命中了正确的索引记录；
• 事务是否因为外部调用而长时间持有锁；
• 更新影响行数是否被应用程序正确检查。

只写一个 SELECT ... FOR UPDATE，却把支付、远程调用、消息发送都放在锁内，往往会把超卖问题变成锁等待、连接池耗尽和吞吐下降问题。

3. 错误表现不只有“库存变成负数”

库存字段没有变成负数，也不代表扣减一致性已经做好。有些实现使用了类似下面的更新：

UPDATE stock
SET available = available - 1

WHERE sku_id = 1001

AND available >= 1;

这类条件更新通常能避免库存被扣到不允许的下限，但它仍然可能存在其他业务错误：

• 接口因网络超时没有收到数据库响应，客户端重试后造成重复扣减；
• 库存扣减成功，但订单落库失败；
• 数据库写入成功，消息发送失败，后续系统没有收到库存变化；
• 主库已经扣减，从库尚未同步，用户看到的仍是旧库存；
• 缓存先扣减但数据库失败，缓存库存长期少于真实库存。

所以，“不超卖”只是库存一致性的一个结果，不是全部结果。设计方案时应先定义业务到底要保证哪一种一致性，再选择技术机制。

三、常见误区：看似加固，实际上没有解决核心风险

1. 误区一：做了参数校验，就不会扣错

参数校验只能阻止数量为零、负数、格式异常或明显超限的请求。例如，购买数量为 2，而库存只有 1，这类请求在进入数据库前就可以被拒绝。

但如果两个请求都购买 1 件，单个请求看起来都合法，组合起来却超过了剩余库存。这个问题属于并发一致性，不是输入合法性问题。

我的判断方式很简单：如果把请求一个一个顺序执行，代码完全正确；一旦并发执行就可能错误，那么重点就不应继续放在参数校验，而应转向原子更新、锁、版本号和事务边界。

2. 误区二：用了事务，就一定不会超卖

事务能够保证同一数据库连接中一组操作的提交边界。例如，库存扣减和库存流水写入处于同一个本地事务中，库存扣减成功但流水写入失败时，可以整体回滚。

但事务不等于并发控制。两个事务都可能先读取到库存 1，然后按照各自的判断继续执行。最终结果取决于数据库的更新方式、隔离级别、锁行为和提交顺序。

更重要的是，事务通常不能自然覆盖以下动作：

• 调用支付服务；
• 修改缓存；
• 向外部消息系统发送通知；
• 写入另一个数据库；
• 调用搜索、营销或配送服务。

因此，更准确的表述是：事务保证它覆盖范围内的数据库操作具有原子提交边界，但不自动保证整个业务链路一致。

3. 误区三：加了行锁，就可以放心了

悲观锁适合资源竞争强、冲突代价高，并且业务能够接受锁等待的场景。它的价值是让多个事务不能同时修改同一行，避免并发更新失控。

但是，锁是否有效取决于锁的对象、范围和生命周期。常见问题包括：

• 查询条件没有命中索引，锁住的范围远大于预期；
• 锁只保护库存行，却没有保护重复请求记录；
• 事务内包含远程调用，导致锁持有时间不可控；
• 事务回滚后，应用没有正确处理重试；
• 多个资源按不同顺序加锁，形成死锁。

在高并发库存场景中，我通常优先考虑“带条件的原子更新”，只有当扣减前后必须读取并校验多项关联状态时，才评估是否需要显式锁。

4. 误区四：用缓存扣减，数据库最后同步就行

缓存适合承接高频读取和流量削峰，但缓存中的数字不一定就是最终账本。若先在缓存中扣减，再异步写数据库，系统必须面对进程重启、消息丢失、重复消费和数据库写入失败。

缓存预扣并不是不能使用，而是需要配套设计：

• 每次预扣是否有唯一业务请求号；
• 预扣成功后是否有可靠消息记录；
• 数据库最终扣减失败后如何回补缓存；
• 缓存与数据库的差异如何定期对账；
• 活动结束后是否以数据库账本为准。

缓存可以优化扣减路径，但不应在没有恢复机制的前提下承担唯一事实来源。

5. 误区五：幂等就是一致性

幂等解决的是同一业务动作被执行多次时，结果仍然只生效一次。例如，客户端发起扣库存请求后没有收到响应，于是使用相同请求号重新发送。系统应识别这是同一笔业务，而不是新的扣减。

但两个不同请求号同时购买最后一件商品，并不属于幂等问题。即使每个请求都有唯一编号，系统仍然必须在库存层面进行并发控制。

四、专业判断逻辑：先定义一致性，再选择技术方案

1. 先问“什么状态不能错”

设计扣减流程之前，我不会先问“要不要上分布式事务”，而会先问三个问题：哪一个数字是最终账本？哪些状态必须同时成立？哪些短暂不一致是业务可以接受的？

例如，库存数量、订单状态和支付状态并不一定需要在同一毫秒完成一致。库存可以先锁定，订单进入待支付，支付成功后再完成最终确认。但如果库存已经扣减，系统却没有任何订单或锁定记录，这就是不可接受的事实丢失。

这个判断会直接影响方案：有些业务需要强一致，有些业务只需要最终一致，还有些业务需要的是“可追溯、可恢复”，而不是所有数据实时相同。

2. 再拆出不变量

不变量是无论并发、失败和重试如何发生，都不能被破坏的业务规则。库存扣减常见的不变量包括：

• 可用库存加已锁定库存，不得超过实际可售总量；
• 同一业务请求最多产生一笔有效扣减；
• 库存扣减流水的总和能够解释库存变化；
• 取消订单释放的数量，不能超过原订单锁定数量；
• 已完成订单不能被重复取消并释放库存。

一旦把不变量写清楚，技术方案就不会停留在“加一个锁”这种模糊层面。你会知道需要什么字段、什么唯一约束、什么状态机和什么对账口径。

3. 最后确定事实写入点

一个系统如果同时把数据库、缓存、消息队列和报表库都当成库存事实来源，迟早会出现“每个地方看起来都有道理”的对账争议。

通常情况下，我会把数据库中的库存流水或账户账本作为事实来源，把缓存视为加速层，把报表视为分析层，把消息视为传播变化的通道。

这并不意味着数据库永远是最适合承受所有流量的组件，而是要明确：性能层可以暂时领先或落后，但事实层必须可验证、可回放、可修复。

4. 用四个问题评审扣减方案

1. 两个不同请求同时扣减最后一件时，谁决定哪个成功？
2. 请求在数据库提交成功后、响应返回前断开连接时，重试如何判断是否已经扣过？
3. 扣减成功后订单写入失败时，库存如何恢复或订单如何补写？
4. 缓存、从库和主库显示不同数字时，哪个数字用于最终结算？

如果一个方案无法明确回答这四个问题，即使代码中有事务、锁和消息队列，也不能认为它已经完成一致性设计。

五、落地实现：从一条 SQL 到完整扣减链路

1. 第一步：在入口处过滤明显非法请求

入口校验的价值在于尽早拒绝不可能成功的请求，避免无效流量占用数据库连接。至少应校验商品编号、扣减数量、请求号和业务状态。

if (skuId == null || quantity  MAX_PURCHASE) {
return reject("invalid request");

}

if (requestId == null || requestId.isBlank()) {

return reject("missing request id");

}

这里的 MAX_PURCHASE 是业务上限，不是并发一致性控制。即使数量合法，也必须在写入数据库时再次检查资源是否足够。

2. 第二步：用条件更新替代应用层的“先查再改”

对于单个 SKU 的可用库存扣减，优先考虑把业务条件放进 UPDATE：

UPDATE stock
SET available = available - :quantity,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = :sku_id

AND available >= :quantity;

应用程序必须检查影响行数，而不是只看 SQL 是否执行成功：

rows = execute(updateSql, params);
if (rows == 1) {

return success();

}

if (rows == 0) {

return reject("insufficient stock or invalid sku");

}

return fail("unexpected affected rows");

“SQL 执行没有报错”和“扣减业务成功”是两回事。数据库驱动返回成功，只能说明语句被数据库接受；只有影响行数符合预期，才能说明目标记录满足条件并完成了扣减。

3. 第三步：给重复请求建立唯一边界

假设一次扣减请求的编号是 REQ-20260916-0001。系统可以在扣减流水表建立唯一约束：

CREATE TABLE stock_deduction_log (
id BIGINT PRIMARY KEY,
request_id VARCHAR(64) NOT NULL,
order_id VARCHAR(64) NOT NULL,
sku_id BIGINT NOT NULL,
quantity INT NOT NULL,
status VARCHAR(20) NOT NULL,
created_at TIMESTAMP NOT NULL,
UNIQUE KEY uk_request_id (request_id)
);

不过，唯一约束只保证相同请求号不能重复落库。它不等于整条业务流程已经幂等，因为还需要定义重复请求读取什么结果：返回原来的成功结果、返回处理中，还是返回明确失败。

4. 第四步：把同库操作放进合理的事务

如果库存表、订单表和扣减流水表位于同一个数据库，可以把它们放入本地事务：

BEGIN;
— 先写入或确认请求幂等记录

INSERT INTO stock_deduction_log
(id, request_id, order_id, sku_id, quantity, status, created_at)
VALUES
(:id, :request_id, :order_id, :sku_id, :quantity, 'PROCESSING', CURRENT_TIMESTAMP);

— 再进行带条件的原子扣减

UPDATE stock
SET available = available - :quantity
WHERE sku_id = :sku_id
AND available >= :quantity;

— 影响行数为 0 时，整个事务回滚

— 影响行数为 1 时，写入订单或更新流水状态

UPDATE stock_deduction_log
SET status = 'SUCCESS'
WHERE request_id = :request_id;
COMMIT;

实际代码还需要处理唯一键冲突、死锁重试、连接断开和事务超时。示例的重点不在于复制执行，而在于展示三个边界：请求去重、库存条件更新和同库操作的提交关系。

5. 第五步：不要让事务包住不可控的远程调用

一个常见但危险的流程是：开启数据库事务，扣减库存，调用支付服务，等待支付结果，再提交数据库事务。这样做会让数据库锁的持有时间受网络、支付服务和用户行为影响。

更稳妥的方式通常是把业务拆成明确状态：

1. 本地事务创建订单并锁定库存；
2. 事务提交后进入待支付状态；
3. 支付服务异步通知订单；
4. 支付成功后确认订单，支付失败或超时后释放锁定库存；
5. 所有状态变化都带业务请求号和状态流转约束。

这不是把所有问题都交给异步，而是把“数据库必须共同提交的事情”和“可以通过状态机最终收敛的事情”分开。

六、案例拆解：库存、余额和优惠券不能用同一套判断

1. 库存扣减：重点是资源不被重复占用

库存通常是最容易被拿来解释一致性的场景，但库存也有不同模型。现货库存、锁定库存、在途库存和可售库存不一定是同一个字段。

如果系统只有一个 available 字段，最基本的扣减可以使用条件更新。但如果订单创建后需要等待支付，就不应直接把所有库存都视为最终销售完成，而应该区分“可用”和“锁定”。

这里的关键不是单纯把库存减一，而是让每次状态变化都有来源、有数量、有唯一业务号，并且不能越过状态机重复执行。

2. 余额扣减：重点是金额精度和可追溯账本

余额扣减与库存扣减看起来相似，但风险更高。库存多扣一件，可能造成履约问题；金额多扣一分钱，则可能引发对账、退款和合规问题。

余额字段不应使用浮点数保存金额。通常应使用定点小数类型，或者使用最小货币单位的整数保存，例如以分为单位。更新时还应带上余额充足条件：

UPDATE account
SET balance_cent = balance_cent - :amount_cent

WHERE account_id = :account_id

AND balance_cent >= :amount_cent;

此外，余额表最好与资金流水表形成可校验关系。余额是当前快照，流水是变化证据。出现争议时，不能只看余额字段，而应核对流水是否能解释余额的变化。

3. 优惠券扣减：重点是唯一使用和状态机

优惠券通常不是简单的数值递减，而是“未使用、锁定、已使用、已过期、已释放”等状态变化。此时，用一个“库存大于零”的判断无法覆盖业务规则。

一个更接近真实业务的更新条件可能是：

UPDATE coupon
SET status = 'LOCKED',

locked_order_id = :order_id,

locked_at = CURRENT_TIMESTAMP

WHERE coupon_id = :coupon_id

AND user_id = :user_id

AND status = 'AVAILABLE'

AND expire_at > CURRENT_TIMESTAMP;

影响行数为 1，表示优惠券被当前订单锁定；影响行数为 0，表示优惠券已经被使用、锁定、过期或不属于当前用户。这里的状态条件就是一致性边界的一部分。

4. 账户额度：重点是并发下的总额约束

额度扣减常见于授信、配额、积分和促销预算。它的难点往往不只是单个账户余额，而是多个维度的约束同时成立，例如个人额度、商户额度、活动总预算都必须足够。

当多个资源必须同时扣减时，单条 SQL 能否覆盖所有条件，会影响方案选择。如果所有资源在同一数据库且更新数量有限，可以在同一事务中按固定顺序更新；如果分布在多个服务，则需要明确部分成功后的补偿路径。

七、不同架构下的行动建议

1. 单体应用、单库单表

这是最适合优先做好基础一致性的场景，不需要一开始就引入复杂的分布式事务。

建议采用以下组合：

• 入口校验数量、状态和请求号；
• 使用带业务条件的原子更新；
• 根据影响行数返回扣减结果；
• 库存流水和订单操作放入本地事务；
• 对请求号建立唯一约束；
• 对死锁和瞬时数据库错误设置有限次数重试；
• 建立库存与流水的定期对账。

这套方案的优势是边界清晰、排查路径短、维护成本低。很多系统的问题不是技术能力不足，而是在单库能解决时过早引入缓存预扣和异步链路，反而增加了恢复难度。

2. 单库高并发、最后库存竞争激烈

当大量请求集中争抢同一行库存时，条件更新仍然可以作为底层正确性保障，但数据库可能成为吞吐瓶颈。

可以按以下顺序优化：

1. 确认更新条件命中唯一或高选择性索引；
2. 减少事务内的非数据库操作；
3. 避免先查询再更新的多余往返；
4. 根据业务接受程度增加限流、排队或活动分片；
5. 必要时引入预扣层，但保留数据库最终确认和对账机制。

这里有一个重要取舍：吞吐提升通常意味着把请求排队、异步化或分散到多个库存桶，但分散之后会增加合并、回补和对账复杂度。不要只看接口每秒处理量，还要看失败请求、回补耗时和异常订单比例。

3. 读写分离场景

扣减完成后，如果业务立即查询库存，读请求可能被路由到存在复制延迟的从库。用户看到旧库存，并不一定表示扣减失败，而可能是读路径没有实现“读己之写”。

可采用以下策略：

• 扣减结果直接以写库返回结果为准，不立即依赖从库查询；
• 涉及用户刚刚完成操作的查询，短时间内强制读主库；
• 通过请求上下文标记最近写入，暂时绕过从库；
• 允许旧读的页面明确区分“实时库存”和“展示库存”；
• 对主从延迟设置监控和告警，而不是等用户投诉。

读写分离解决的是读取压力，不会自动提升扣减一致性。写入仍应在事实数据库上完成，读副本只负责在业务允许的范围内提供查询服务。

4. 缓存预扣场景

缓存预扣适合流量突发、库存热点明显且业务能够接受异步确认的场景。它的前提不是“缓存比数据库快”，而是系统愿意为速度支付额外的状态管理成本。

至少需要建立以下链路：

1. 为每次预扣生成唯一业务请求号；
2. 缓存预扣成功后，记录可恢复的业务事实；
3. 通过可靠消息通知数据库或库存服务；
4. 消费端根据请求号实现幂等；
5. 数据库失败时执行重试或释放预扣；
6. 定时比较缓存、数据库和订单事实，处理差异。

如果业务无法接受短暂超卖、无法接受异步确认，或者团队没有能力维护对账与补偿，那么不建议仅因为追求峰值吞吐就采用缓存预扣。

5. 微服务和跨数据库场景

当订单服务、库存服务、支付服务各自拥有独立数据库时，本地事务只能保证各服务自己的数据。此时应把业务拆成可追踪的状态流转，而不是假设一条远程调用链可以拥有单库事务的特性。

一种常见的可靠流程是：

• 订单服务本地事务写入订单和待处理事件；
• 事件发布组件持续投递库存扣减消息；
• 库存服务按业务请求号幂等消费；
• 库存服务返回成功、失败或处理中状态；
• 订单服务根据结果流转状态；
• 异常状态进入重试、补偿和人工处理队列。

这个模式的关键不在于消息队列本身，而在于“业务事实先可靠落库，再传播出去”。如果消息发送成功依赖应用在事务提交之后临时执行，一旦进程在两个动作之间崩溃，就会出现数据库已有变化但消息没有发出的间隙。

八、如何做验证：不要只测成功路径

1. 并发测试至少覆盖四种情况

我在评审扣减功能时，最先看的不是正常下单是否成功，而是四类边界测试是否有明确结果。

如果测试只验证“库存充足时能够扣减”，只能证明功能路径可用，不能证明扣减链路具备一致性。

2. 重点记录影响行数和业务状态

对于条件更新，影响行数是非常有价值的诊断信号。影响 0 行可能意味着库存不足，也可能意味着 SKU 不存在、状态不符合或参数条件错误。不能把所有 0 行都简单返回成“库存不足”。

建议在日志和指标中区分：

• 资源不足次数；
• 重复请求次数；
• 条件不匹配次数；
• 数据库死锁重试次数；
• 事务回滚次数；
• 消息重复消费次数；
• 库存与流水对账差异次数。

这些指标比单纯监控接口成功率更能解释一致性问题发生在哪里。接口成功率很高，但重复扣减和对账差异持续增加，仍然说明系统存在隐蔽风险。

3. 用流水反推快照是否可信

库存快照适合快速读取，流水适合审计和恢复。对于一个 SKU，可以用以下思路核对：

理论库存
= 初始库存

+ 入库流水总量

成功扣减流水总量

+ 释放库存总量

盘亏调整总量;

这里的具体公式必须根据业务模型调整。例如锁定库存和已售库存分开记录时，不能把所有状态简单相加减。重点是每一类库存变化都要有明确的业务来源和唯一编号。

4. 观察“失败后是否可恢复”，而不只是“是否失败”

分布式系统不可能让所有异常都消失。更现实的工程目标是：异常发生后，系统能够发现、定位、重试、补偿，并且不会在恢复过程中产生新的重复扣减。

因此，测试时应主动制造以下故障：

• 数据库连接在提交附近断开；
• 消息发送成功但消费端响应超时；
• 消费端处理成功后确认消息失败；
• 缓存更新成功但数据库更新失败；
• 订单取消和支付成功同时到达；
• 释放库存任务重复执行。

每个故障都应有明确的最终状态，而不是依赖运维人员手工修改一行库存数字。

九、不同方案的取舍：一致性、性能和复杂度不能同时无限提高

1. 先查再扣与条件更新

我的建议是：先查可以保留，但最终扣减必须再次由数据库条件保护。前置查询用于友好提示，条件更新用于最终裁决，两者不是互斥关系。

2. 乐观锁与悲观锁

乐观锁通常在记录中增加版本号：

UPDATE stock
SET available = available - :quantity,

version = version + 1

WHERE sku_id = :sku_id

AND available >= :quantity

AND version = :version;

如果影响行数为 0，说明库存不足或版本已经变化，应用可以返回失败或重新读取后重试。

乐观锁适合冲突相对可控、失败后可以快速重试的场景。它不会长时间阻塞其他请求，但冲突集中时，重试会放大数据库压力。

悲观锁更适合必须串行化处理、且冲突失败代价很高的场景。它的代价是锁等待、死锁和吞吐下降，需要严格控制事务范围。

3. 同步事务与异步消息

同步事务的优点是结果明确，调用方在返回前就知道数据库是否完成。缺点是链路长时响应时间增加，并且跨服务场景难以覆盖全部操作。

异步消息适合削峰、解耦和跨服务传播状态，但它引入了延迟、重复消费、消息积压和补偿问题。异步不是天然更可靠，只有当消息可持久化、可重试、可监控、可对账时，才真正具备工程价值。

选择标准不应是“同步老旧、异步先进”，而应看业务是否允许：

• 几百毫秒到数秒的状态延迟；
• 订单先创建、库存后确认；
• 失败后通过补偿最终恢复；
• 用户在短时间内看到处理中状态。

4. 强一致与最终一致

强一致适合金额扣减、关键配额和不能出现中间错误状态的核心账本。最终一致适合订单通知、搜索索引、报表同步和非关键展示数据。

但“最终一致”不是“不管它最后会自己好”。一个合格的最终一致方案必须回答：

1. 谁是最终事实来源；
2. 差异多久能够被发现；
3. 失败消息如何重试；
4. 重复执行如何保证安全；
5. 无法自动修复时谁来处理；
6. 修复后如何留下审计记录。

十、架构师的一页检查清单

1. 数据校验层

• 扣减数量是否大于零；
• 数量是否不超过单次购买上限；
• 商品、账户、券或额度记录是否存在；
• 当前业务状态是否允许扣减；
• 请求号是否存在且格式符合要求；
• 是否在服务端重新校验，而不是只相信前端。

2. 数据库写入层

• 最终扣减是否使用带条件的更新；
• 更新条件是否命中正确索引；
• 是否检查影响行数；
• 数值类型是否可能溢出或出现精度问题；
• 是否有非负约束、唯一约束或状态约束；
• 是否记录更新前后数量或可追溯流水。

3. 事务边界

• 哪些表必须共同提交；
• 事务是否包含远程调用；
• 事务失败后是否能够安全重试；
• 死锁是否有有限次重试和告警；
• 事务超时是否会导致业务状态悬挂；
• 是否明确主库提交成功但响应丢失时的处理方式。

4. 幂等与状态机

• 每次业务动作是否有唯一请求号；
• 重复请求能否返回原处理结果；
• 重复消息是否不会重复改变资源数量；
• 取消、支付、释放和确认是否有合法状态转换；
• 状态更新是否带旧状态条件；
• 是否禁止已完成状态被无条件覆盖。

5. 异步与补偿

• 事件是否先落库再投递；
• 消息是否有重试次数和死信处理；
• 消费结果是否可查询；
• 缓存与数据库是否有定期对账；
• 异常差异是否能定位到订单、请求号和流水；
• 人工修复是否会留下操作记录。

6. 监控与验证

• 库存负数次数是否为零；
• 重复请求和重复消费次数是否可见；
• 数据库死锁、锁等待和事务回滚是否有指标；
• 主从延迟是否超过业务允许范围；
• 对账差异是否能够自动告警；
• 失败订单是否有明确的最终状态。

十一、下一步怎么做：从一次 SQL 评审开始

1. 先画出真实链路，而不是先换技术

把一次扣减从入口到结束完整画出来，包括参数校验、读取、写入、事务提交、缓存修改、消息投递和用户响应。尤其要标记每个可能失败的时间点。

很多团队只画“成功流程”，没有画“提交成功但响应失败”“消息成功但消费超时”“取消与支付同时到达”等异常流程。没有异常流程图，就无法判断补偿是否真实存在。

2. 把所有“先查再改”找出来

在代码仓库中搜索库存、余额、额度、优惠券等资源的读取和更新逻辑，重点检查它们是否跨越了应用层判断。对于单行数值扣减，优先评估是否可以改成条件更新。

如果业务确实需要先读取多个字段，也要确认最终写入是否带版本号、状态条件或锁保护。不能因为前面查过一次，就默认后面的更新仍然安全。

3. 为每个动作补上业务请求号

请求号不是为了方便打印日志，而是为了在超时和重试时回答一个关键问题：这次业务到底处理过没有？

请求号应贯穿订单、扣减流水、消息和补偿记录。只有各个环节使用同一个可关联标识，系统才能在发生差异时从一条订单追到一次扣减，再追到一条消息和一次恢复操作。

4. 先补测试，再考虑复杂架构

在引入缓存预扣、分布式事务或复杂消息编排之前，先用两个并发请求、一个重复请求和一次模拟故障验证现有实现。如果最基础的条件更新、影响行数判断和幂等边界都没有做好，架构复杂化只会把问题分散到更多组件。

最终可以按以下顺序推进：

1. 修正参数校验和业务状态校验；
2. 将最终扣减改为数据库条件更新；
3. 增加影响行数判断和明确失败原因；
4. 增加业务请求号、唯一约束和幂等返回；
5. 划定本地事务范围，移除事务内远程调用；
6. 为异步链路增加可靠投递、重复消费和补偿；
7. 建立流水、快照和订单之间的对账机制。

十二、结语：真正可靠的扣减，不是“校验更多”，而是让错误没有落点

数据校验当然重要，但它解决的是“请求是否值得继续处理”。如果系统把校验结果存放在应用变量里，再过一段时间才去更新数据库，那么这个结果随时可能过期。

扣减一致性的关键，是让资源条件与实际更新尽可能成为同一个受数据库保护的动作；当库存、订单和流水需要共同成立时，再用本地事务组合；当请求可能重试时，用唯一业务号和状态机去重；当链路跨越服务和消息系统时，用可靠事件、补偿和对账让状态最终收敛。

下一步不必先选某个热门组件。先拿系统中最容易出问题的一条扣减链路，回答四个问题：谁是事实来源、谁决定扣减成功、重复请求如何处理、失败后如何恢复。只要这四个答案清楚，技术方案通常不会偏离太远。

校验是前置判断，一致性是全过程约束；校验通过，只代表可以尝试扣减，只有原子更新、事务、幂等和补偿共同闭环，才代表系统真正有能力把资源扣对。

SELECT available FROM stock WHERE sku_id = 1001;
if available >= quantity:
UPDATE stock SET available = available - quantity WHERE sku_id = 1001;假设库存只有 1，用户 A 和用户 B 几乎同时发起购买。

UPDATE stock SET available = available - :quantity, updated_at = CURRENT_TIMESTAMP WHERE sku_id = :sku_id AND available >= :quantity;

免费注册

咨询方案

扫码咨询方案