数据库存：数据库管理员实操指南：围绕事务一致性解决“设计难扩展”

我处理过一个订单系统，最初每天只有几万笔写入，单库事务完全够用；半年后业务拆成订单、库存、优惠券和结算四个服务，开发团队却仍然沿用“一个接口里更新所有表”的设计。结果一到大促，库存扣减成功但订单状态未提交、优惠券已核销却支付失败、补偿任务反复执行，数据库连接池和锁等待同时升高。真正限制系统扩展的，不是数据库表数量，而是事务边界没有随着业务边界一起重新设计。

本文不把事务一致性简单归结为“使用更高隔离级别”或“加分布式事务”。我会从数据库管理员的实际工作出发，拆解如何识别一致性目标、划分事务边界、处理跨库写入、设计幂等与补偿、验证异常场景，并用可观测指标判断一套设计究竟是稳定扩展，还是把问题推迟到下一次流量峰值。

一、先讲核心结论：可扩展的一致性不是“所有事情同时成功”

1. 先区分四种不同的一致性要求

很多系统设计会议会直接提出“必须保证强一致”，但这个结论通常缺少业务定义。数据库管理员真正需要确认的是：哪些数据必须在同一个瞬间完成状态转换，哪些数据可以延迟，哪些数据允许最终修正。

• 原子性一致：同一个本地事务中的关键写入要么全部成功，要么全部回滚，例如订单主表与订单行项目。
• 约束一致：任何时刻都不能违反唯一键、外键、余额不能为负等约束。
• 业务最终一致：跨服务的数据可以短暂不同，但必须有可靠事件、重试和对账机制完成收敛。
• 查询视图一致：报表、搜索索引、缓存等派生数据允许存在延迟，但延迟需要可观测、有上限。

如果把这四类一致性全部放进一个长事务，系统会获得较强的瞬时一致性，却失去并发能力、故障隔离能力和水平扩展能力。我的判断是：一致性应当按业务损失定级，而不是按技术团队的偏好定级。

2. 事务边界决定系统能否继续拆分

一个事务边界应该满足三个条件：第一，参与写入的数据属于同一个业务事实；第二，失败后可以用回滚恢复；第三，事务持续时间能够被稳定控制。如果一个事务同时包含远程 HTTP 调用、文件上传、消息发送和多张核心表更新，它实际上已经超出了数据库事务适合承担的范围。

我通常会先问一句：“如果这个事务执行到一半，服务进程被杀死，哪些结果必须立即撤销，哪些结果可以通过后续动作补齐？”答案往往能直接暴露设计中的混杂边界。

3. 扩展的优先级不是先上分布式事务，而是先缩短本地事务

在实际优化中，最有效的顺序通常是：

1. 把外部调用移出数据库事务。
2. 将核心状态写入压缩为一个短事务。
3. 通过唯一约束和幂等键保证重复请求不产生重复结果。
4. 使用本地消息表或可靠事件机制传递后续动作。
5. 为失败事件设计重试、死信、人工介入和对账路径。
6. 只有在业务确实不能接受最终一致时，再评估两阶段提交或其他分布式事务方案。

二、背景和真实场景：为什么设计一开始能跑，后来却难扩展

1. 单体系统里的“大事务”容易掩盖边界问题

在单体应用初期，订单创建、库存扣减、积分增加可能都在一个数据库实例内完成。开发人员只需要开启一次事务，调用多个服务类方法，最后统一提交。这种方式上线快，也容易写测试，因此很容易被误认为是长期正确的架构。

问题在于，早期的模块边界通常只是代码目录边界，而不是数据所有权边界。订单模块可以直接更新库存表，营销模块可以直接修改订单优惠字段，财务模块又可以读取并改写支付状态。系统规模变大后，任何一个表结构调整都可能影响多个服务，事务也无法轻易跨越新的服务边界。

2. 典型故障不是“事务失效”，而是事务覆盖范围失控

我见过一类非常典型的代码：先创建订单，再调用库存服务，再调用优惠券服务，最后发送支付通知。开发者为了“保证一致性”，把整个流程包装在一个数据库事务里。然而数据库只能回滚自己的写入，无法回滚已经发出的 HTTP 请求，也无法阻止远程服务继续处理。

当库存服务响应超时，调用方无法判断库存到底扣成功还是没扣成功。此时事务回滚了订单本地写入，但库存可能已经减少。系统表面上没有脏数据，业务上却出现了真实库存损失。这不是隔离级别可以解决的问题，而是远程副作用与本地事务混在一起造成的结果。

3. 事务一致性问题通常在三个时点集中爆发

• 流量突然升高时：锁等待、连接池耗尽、死锁重试和事务超时互相放大。
• 服务拆分时：原本一次提交变成多个数据库或多个服务之间的状态协同。
• 数据修复时：系统没有记录业务意图，只保留最终状态，管理员无法判断哪些记录应当重试。

因此，我不会只在发布前查看事务是否提交成功，而会把故障恢复纳入设计评审：如果消息重复投递三次，结果是否相同？如果消费者处理成功但确认消息失败，下一次是否会重复扣款？如果主库切换发生在提交返回之前，调用方如何判断结果？

4. 用一个订单闭环看清数据所有权

订单服务应该拥有订单生命周期，例如待支付、已支付、已取消和已完成；库存服务拥有可售库存、锁定库存和已扣减库存；优惠券服务拥有券的核销状态；支付服务拥有支付单和支付渠道结果。每个服务可以发布事实事件，但不应直接修改另一个服务的核心表。

这种拆分并不意味着所有数据都必须物理分库。即使短期内仍然使用同一个数据库实例，也可以先通过访问权限、数据访问层和表所有权约束形成逻辑边界。先建立数据责任边界，再决定是否物理拆分，通常比先分库、后补一致性更稳妥。

三、常见误区：看似增强一致性，实际降低可用性

1. 误区一：把隔离级别当成业务一致性方案

READ COMMITTED、REPEATABLE READ、SERIALIZABLE 解决的是并发事务之间如何观察和影响数据，不会自动解决跨服务写入、消息重复、外部支付成功后本地回滚等问题。隔离级别越高，通常意味着更多锁冲突、回滚或重试成本，不能脱离业务场景直接选择。

例如，库存扣减需要防止超卖，重点可能是条件更新、版本号或数据库行锁；而报表查询需要的是一个可接受的时间点视图，重点可能是快照、只读副本或批量汇总。两者都叫“一致性”，但实现路径完全不同。

2. 误区二：用“先查再改”代替原子条件更新

下面这种逻辑在并发环境中很危险：先查询库存是否大于零，应用层判断通过后，再执行扣减。两个请求可能同时读到库存为一，随后都执行扣减，最终产生负库存或重复销售。

SELECT available_quantity
FROM inventory

WHERE sku_id = 1001;

-- 应用层判断 available_quantity > 0 后再执行

UPDATE inventory

SET available_quantity = available_quantity - 1

WHERE sku_id = 1001;

更稳妥的做法是让判断与修改成为一个原子条件，并检查受影响行数。数据库没有更新到任何行时，应用就知道库存不足或版本已变化。

UPDATE inventory
SET available_quantity = available_quantity - 1,

version_no = version_no + 1,

updated_at = CURRENT_TIMESTAMP

WHERE sku_id = 1001

AND available_quantity > 0

AND version_no = 23;

不过，乐观锁并不是万能方案。热点商品在高并发下会产生大量版本冲突，重试会进一步放大数据库压力。此时需要配合库存分片、队列削峰、分段库存或按商品热度采用不同扣减策略。

3. 误区三：把发送消息放在提交事务之前

如果应用先发送“订单已创建”消息，再提交订单事务，消费者可能先查不到订单；如果随后数据库提交失败，系统又已经把一个不存在的订单传播出去。反过来，如果先提交事务再发送消息，进程可能在提交成功后崩溃，导致数据库有订单、消息却没有发出。

这就是经典的“数据库写入与消息发送双写问题”。它不是简单调整代码顺序就能彻底解决的，需要将消息意图作为本地事务的一部分保存下来，再由可靠投递程序异步发送。

4. 误区四：所有操作都使用重试，重试次数越多越可靠

重试只有在操作满足幂等条件时才安全。创建订单、扣减余额、发放优惠券等操作，如果没有业务幂等键，重试可能产生重复订单、重复扣款或重复发券。

另外，重试还应区分异常类型。死锁、临时连接断开、只读副本延迟，可能适合短暂重试；参数错误、唯一键冲突、余额不足，则不应盲目重试。我的经验是，重试策略必须同时记录请求标识、业务幂等键、异常分类、重试次数和下一次执行时间，否则它只是隐藏故障的自动化脚本。

5. 误区五：使用分布式事务就可以消除所有补偿逻辑

两阶段提交可以协调多个资源参与者，但它会引入协调者状态、参与者锁持有、网络阻塞和故障恢复问题。一个参与者已经准备提交，协调者却长时间不可用时，事务可能处于不确定状态，资源也可能被占用。

在跨服务订单流程中，分布式事务还不能回滚支付渠道已经完成的扣款，也无法撤销用户收到的短信或已经消耗的第三方资源。因此，即便采用分布式事务，也仍然需要超时处理、状态查询、人工对账和业务补偿。

四、专业判断逻辑：先定义不变量，再选择技术方案

1. 第一步：写出业务不变量，而不是先讨论框架

业务不变量是无论并发、重试、宕机还是网络抖动，都不能被破坏的规则。例如“已支付订单不能回到待支付”“一张优惠券只能核销一次”“账户可用余额不能低于零”“订单总金额必须等于订单行金额之和”。

我会要求团队把每条不变量标记为三类：可以由数据库约束保证的、需要事务保证的、只能通过异步对账保证的。这样可以避免把所有责任都压给数据库，也避免把本可由唯一键解决的问题交给复杂的分布式协调。

2. 第二步：判断数据是否属于同一个业务事实

如果两张表记录的是同一件事的不同组成部分，例如订单主表和订单行表，它们通常应放在同一个本地事务中。如果一张表记录订单创建，另一张表记录支付渠道回调，两者属于不同业务事实，不宜为了“看起来同步”而强行放进一个事务。

判断标准可以很具体：当第二个事实失败时，是否需要撤销第一个事实？如果答案是“需要撤销”，再继续问撤销是否由数据库回滚完成。如果撤销必须调用远程接口或触发另一套业务流程，那么更合理的设计通常是状态机加补偿，而不是无限扩大事务。

3. 第三步：确定一致性窗口

一致性窗口是数据从一个事实状态传播到相关视图或下游系统所允许的最长时间。订单创建到搜索可见可能允许几秒，支付成功到权益到账可能允许几十秒，但余额扣减到可用余额显示通常需要更严格的实时性。

没有一致性窗口，就没有办法设置告警阈值。比如事件平均延迟只有200毫秒，但最大延迟达到20分钟，业务可能仍然感知为严重故障。监控应同时观察平均值、P95、P99和超时记录数量。

4. 第四步：选择约束、锁、版本号或事件机制

5. 第五步：检查故障发生在“提交前、提交中还是提交后”

数据库管理员做一致性设计时，不能只问“成功和失败怎么办”，还要处理提交结果不确定的中间状态。客户端收到超时，不代表事务一定失败；数据库返回连接断开，也不代表提交一定没有发生。

对于关键写操作，我会要求建立结果查询接口：调用方携带幂等键提交请求，若响应超时，可以通过同一个幂等键查询最终状态，而不是重新发起一个全新请求。这样才能把“未知结果”转化为“可查询结果”。

五、具体案例：用订单、库存和支付流程验证设计是否可扩展

1. 原始设计：一个接口包办全部动作

假设用户提交订单后，系统依次执行创建订单、扣减库存、核销优惠券、创建支付单和发送通知。原始设计把这些动作放在一个应用事务中，代码逻辑大致如下：

begin;
insert into orders (...);

update inventory set available_quantity = available_quantity - 1 where sku_id = ?;

update coupons set status = 'USED' where coupon_id = ?;

call payment_service.create_payment(...);

insert into notifications (...);

commit;

这个设计有四个结构性问题。第一，远程支付调用延长了数据库事务；第二，优惠券和库存可能属于其他服务，数据库回滚无法覆盖远程动作；第三，通知写入与消息投递职责不清；第四，任何一步超时都会让调用方无法判断前面动作是否已经生效。

如果数据库连接池配置为100个连接，平均事务耗时从80毫秒增长到800毫秒，理论上可处理的并发事务能力会显著下降。实际吞吐还会受到锁竞争、网络等待和线程调度影响，因此不能简单用公式预测，但长事务造成连接占用和锁等待叠加是确定的风险。

2. 重构设计：先提交订单事实，再推进后续状态

重构后的本地事务只处理订单事实、幂等记录和事件记录。库存、支付和通知由各自消费者根据事件推进，订单状态通过明确的状态机变化。

begin;
— 1. 记录请求幂等键，重复请求直接返回已有结果

insert into request_deduplication
(request_key, business_type, business_id, created_at)
values
(?, 'CREATE_ORDER', ?, current_timestamp);

— 2. 创建订单及订单行

insert into orders
(order_id, user_id, status, total_amount, created_at)
values
(?, ?, 'PENDING_STOCK', ?, current_timestamp);
insert into order_items
(order_id, sku_id, quantity, unit_price)
values
(?, ?, ?, ?);

— 3. 在同一事务内记录待投递事件

insert into outbox_events
(event_id, event_type, aggregate_id, payload, status, created_at)
values
(?, 'ORDER_CREATED', ?, ?, 'PENDING', current_timestamp);
commit;

事务提交成功后，投递程序读取待发送事件并发布到消息系统。消费者处理库存锁定时，使用事件编号和订单编号做幂等控制；库存不足时发布库存失败事件，订单状态从待锁库存转为库存不足；支付成功时，订单再转为已支付。

这里最关键的变化不是“用了消息队列”，而是订单创建成为一个可独立确认的业务事实。后续动作可以失败，但失败有明确状态、有重试入口，也不会让数据库事务一直等待远程服务。

3. 本地消息表必须具备哪些字段

4. 幂等不是一句“判断一下是否处理过”

幂等记录本身也要参与事务。消费者处理库存时，应先尝试写入消费记录；如果写入因唯一键冲突而失败，说明该事件已经成功处理或正在被其他线程处理，需要根据状态决定返回、等待或重试。

begin;
insert into event_consumed

(consumer_name, event_id, aggregate_id, consumed_at)

values

('inventory-service', ?, ?, current_timestamp);

— 只有首次插入成功才继续执行业务动作

update inventory
set locked_quantity = locked_quantity + ?,
available_quantity = available_quantity - ?
where sku_id = ?
and available_quantity >= ?;

— 根据更新行数判断库存锁定是否成功

insert into inventory_reservations
(reservation_id, order_id, sku_id, quantity, status)
values
(?, ?, ?, ?, 'LOCKED');
commit;

实际实现时，需要注意“先写消费记录后业务更新”可能在业务更新失败时留下错误的已消费标记。因此更稳妥的方式是让消费记录、业务更新和结果事件处于同一个本地事务中；如果业务更新失败，消费记录也一起回滚，事件就可以重试。

5. 用状态机代替互相覆盖的状态字段

订单状态必须定义合法迁移，而不是允许多个服务直接写入任意字符串。比如待锁库存可以迁移到库存已锁定或库存不足；库存已锁定可以迁移到待支付或已取消；待支付可以迁移到已支付或支付超时。已支付不能直接回到待支付。

六、数据库管理员的落地方法：从表结构到监控闭环

1. 先建立事务清单，而不是只看慢查询

数据库管理员可以为每类写事务建立清单，至少包含事务名称、涉及表、平均耗时、P95耗时、锁类型、隔离级别、最大重试次数和失败后的恢复方式。慢查询只能告诉你某条 SQL 执行慢，事务清单才能告诉你为什么这些 SQL 被放在一起。

• 列出所有写入核心表的接口。
• 标注接口是否包含远程调用、文件操作或消息发送。
• 统计事务开始到提交的完整耗时，而不是只统计 SQL 执行耗时。
• 查看事务中最早获得的锁和最后释放的锁。
• 找出超过一致性窗口仍未收敛的业务记录。

2. 索引设计要围绕事务访问路径

一致性设计中的索引，不只是为了让查询更快。一个缺失索引的更新语句可能扫描大量记录，锁住比预期更大的范围，进而导致无关业务排队。尤其是库存、账户、任务表等高频更新表，必须检查更新条件是否能够命中精确索引。

例如，事件投递程序通常会按状态和时间拉取任务。如果只有 status 单列索引，待处理记录很多时仍可能扫描大量历史数据。可以根据数据库类型和数据分布设计组合索引，并通过执行计划验证是否真正减少扫描范围。

CREATE INDEX idx_outbox_pending_retry
ON outbox_events (status, next_retry_at, created_at);

SELECT event_id, event_type, aggregate_id, payload

FROM outbox_events

WHERE status = 'PENDING'

AND next_retry_at <= CURRENT_TIMESTAMP

ORDER BY created_at

LIMIT 100

FOR UPDATE SKIP LOCKED;

是否使用 SKIP LOCKED 要结合数据库版本、任务并发模型和公平性要求判断。它可以让多个投递 worker 避免互相等待，但也可能使长期锁住或反复失败的任务被跳过，因此必须搭配积压监控和超时扫描。

3. 死锁处理应从“重试”追溯到访问顺序

死锁的根因通常不是数据库偶然抽风，而是两个事务以不同顺序锁定相同资源。例如事务甲先锁订单再锁库存，事务乙先锁库存再锁订单。数据库会终止其中一个事务，应用若直接重试，可能暂时恢复，但访问顺序不统一的问题仍然存在。

我的处理顺序是：先保留死锁日志，确认参与事务和锁资源；再统一相关代码的资源访问顺序；然后缩短事务并减少不必要的查询；最后才设置有限次数的随机退避重试。重试是最后一道保险，不应成为主要解决方案。

4. 监控必须覆盖数据库、事件和业务结果

只看数据库 CPU、内存和连接数是不够的。事务一致性故障经常表现为数据库资源正常，但事件积压、订单长时间处理中、支付对账差异持续增加。

5. 对账不是失败设计的补丁，而是最终一致性的组成部分

只要系统存在跨服务、跨库或第三方渠道，就无法完全排除状态不确定。对账任务应当定期比较订单、支付、库存和事件记录，找出“订单已支付但库存未扣减”“支付渠道成功但本地支付单处理中”“库存已释放但订单仍待取消”等异常组合。

对账结果不能只导出 Excel 交给运营。应当为每类差异定义自动修复策略、最大重试次数和人工处理入口。自动修复必须保留操作日志和前后状态，避免一次修复造成第二次数据污染。

七、不同情况下的行动建议：不要用同一套一致性方案解决所有系统

1. 低并发、单库、强约束业务

如果系统规模较小，所有核心数据在同一个数据库内，且业务要求即时一致，优先使用本地事务、唯一约束、外键或检查约束。此时不必为了追求架构先进而引入消息队列和分布式事务。

但即便是单库系统，也应避免把外部调用放在事务内。可以在事务中记录待处理任务，提交后由后台 worker 执行。这样做的价值不是立即提升吞吐，而是让未来拆分服务时不必重新定义全部业务流程。

2. 中等并发、跨模块但仍可接受秒级延迟

这类系统适合采用本地事务加可靠事件。核心服务写入事实，事件表记录后续动作，消费者通过幂等键处理。状态机负责表达处理中、失败和补偿中，监控则关注最老事件年龄和未收敛业务记录。

此阶段最容易踩的坑是把事件当作“通知”，却没有把事件处理结果持久化。没有消费记录、处理状态和错误原因，系统就无法区分“没收到”“处理失败”“已经处理但响应丢失”。

3. 高并发、热点库存或账户更新

热点数据不应只依靠加大数据库锁等待上限来解决。可以采用条件更新、乐观锁、库存分片、预扣库存、排队削峰等组合方案。账户余额这类强约束数据，仍需把扣减和余额校验放在同一数据库事务内，不能为了吞吐把关键约束完全异步化。

如果热点行更新冲突严重，可以按账户或商品将写入串行化，但要接受延迟增加；也可以把可售资源拆成多个桶，降低单行竞争，但查询和回收逻辑会更复杂。选择前必须用真实热点分布压测，而不是只看平均请求量。

4. 多数据库、多地域和第三方渠道参与

在多地域场景下，网络分区、复制延迟和时钟差异会使“全局立即一致”变得昂贵。此时要明确哪些数据必须归属一个主写区域，哪些数据允许异步复制，哪些读取需要携带版本号或时间戳。

第三方支付、物流和短信等外部系统不能被数据库事务真正控制。应当使用业务状态机、请求幂等键、渠道查询接口和定期对账。对于支付结果不确定的订单，最危险的做法是根据一次超时就直接关闭订单并释放资源。

5. 旧系统没有事件表，无法一次性重构

不要试图一次重写全部服务。可以选择一个影响面较小但故障频率较高的流程，先增加幂等键和操作日志，再把远程调用移出事务，最后引入本地消息表或任务表。每一步都保留旧逻辑的结果对比，确认业务差异可控后再扩大范围。

渐进式改造的关键是建立“事实表”和“派生表”的区别。先保证核心事实稳定写入，再允许搜索、报表、通知等派生数据逐步迁移。改造期间可以双写，但双写必须有对账，不应把两套写入当成天然一致。

八、不同情况下的取舍：一致性、吞吐、复杂度和成本不可能同时最大化

1. 强一致与高吞吐之间的取舍

把更多操作放进同一个事务，通常可以简化业务判断，减少短暂不一致，但会增加锁持有时间和失败回滚范围。将操作拆成异步事件，可以提升吞吐和故障隔离能力，却需要承担状态延迟、重复消费和补偿运维成本。

2. 数据库约束与应用补偿之间的取舍

数据库约束的优势是可靠、集中、难以绕过；缺点是跨服务和复杂条件下不够灵活。应用补偿可以表达丰富业务规则，但代码可能被重复调用、版本不一致或部署错误影响。

我的原则是：能由数据库直接表达的不变量，尽量不要只靠应用约定。例如唯一业务编号、非负数量、状态枚举、必要字段和同一租户内的唯一关系，都应尽可能落到数据库约束或明确的原子 SQL 中。跨系统的业务协同，再交给事件和补偿。

3. 自动修复与人工介入之间的取舍

自动重试适合临时网络故障、短暂锁冲突和消费者重启；不适合业务规则错误、金额不一致和渠道状态长期未知。自动化程度越高，越需要设置保护阈值，否则系统可能在错误数据上高速重复操作。

我会为自动修复设置三个边界：单条记录最大重试次数、同一业务对象最大修复次数、全局异常比例阈值。超过边界后进入人工队列，并冻结可能继续扩大损失的后续动作。例如支付状态不明时，可以暂停自动释放库存，而不是继续执行取消。

4. 规范化与读性能之间的取舍

为了减少跨表事务，有些团队会把订单、用户、商品信息全部冗余到一张宽表中。这样确实能减少查询和联表，但会引入更新一致性问题。我的建议是区分“交易事实快照”和“实时主数据”：下单时保存商品名称、价格等不可变快照；商品当前库存和用户当前等级仍由各自领域维护。

读模型可以异步构建，但要显示更新时间或版本号。用户看到的是“截至某时间的数据”，而不是让前端误以为所有页面都实时一致。透明地展示延迟，往往比隐藏延迟后产生投诉更可控。

九、验证与上线：不要用一次成功压测证明一致性

1. 测试必须覆盖故障注入

普通接口测试只能验证正常路径，无法验证事务一致性。上线前应主动注入进程终止、数据库连接断开、消息确认丢失、消费者重复执行、主库切换、第三方接口超时等故障。

• 在本地事务提交前终止应用，确认订单和事件是否同时不存在。
• 在提交成功后、事件投递前终止应用，确认事件能否被重新扫描。
• 在消费者业务更新成功后模拟确认失败，确认重复消费不会重复扣减。
• 在支付渠道返回超时后查询最终状态，确认订单不会被错误关闭。
• 并发提交相同幂等键，确认只有一个业务事实成功创建。
• 并发更新同一库存，确认库存不会低于零，失败请求有清晰原因。

2. 压测指标要看P99和积压年龄

平均事务耗时很容易掩盖长尾。数据库管理员至少要观察提交耗时P50、P95和P99，锁等待P99，死锁次数，连接池使用率，事务回滚率，以及事件队列中最老记录的年龄。

如果平均事件延迟为300毫秒，但最老事件已积压15分钟，说明系统并非健康，只是少量正常事件拉低了平均值。对于异步流程，积压年龄通常比平均吞吐更接近用户实际感受。

3. 进行数据不变量巡检

可以建立定时 SQL 或数据质量任务，检查不变量是否被破坏。例如订单总额与明细合计是否一致、可用库存加锁定库存是否等于总库存、已支付订单是否存在支付成功凭证、已核销优惠券是否关联有效订单。

SELECT order_id,
total_amount,

item_amount

FROM order_amount_check

WHERE total_amount <> item_amount

AND checked_at >= CURRENT_DATE;

SELECT sku_id,

total_quantity,

available_quantity,

locked_quantity

FROM inventory

WHERE available_quantity < 0

OR locked_quantity < 0

OR available_quantity + locked_quantity > total_quantity;

巡检任务不应只在发现异常后临时编写。对于金额、库存、余额等高风险数据，应该形成固定报表、阈值告警和修复审批流程，确保异常有持续反馈。

4. 灰度发布要同时比较新旧路径

改造事务边界时，不能只比较接口成功率。还应对比重复请求率、状态停留时间、事件积压、库存差异、支付对账差异和人工介入量。新路径接口更快，但如果异常状态增加，说明一致性成本被转移到了业务后端。

灰度期间最好保留业务对象级别的关联键，把一次请求、一个订单、多个事件和补偿任务串联起来。没有全链路关联键，遇到异常时只能依赖时间、用户和金额模糊搜索，排查效率会明显下降。

十、最终检查清单：判断设计是否真的变得可扩展

1. 事务边界检查

• 事务内是否包含远程 HTTP、RPC、文件上传或第三方调用？
• 事务是否只包含同一业务事实所需的核心表？
• 是否有明确的超时上限和回滚行为？
• 是否统计了事务P95、P99和锁持有时间？
• 是否存在无法解释的长事务和空闲事务？

2. 幂等与重复检查

• 每个外部请求是否拥有稳定的业务幂等键？
• 数据库是否用唯一约束兜底，而不是只靠代码判断？
• 消息消费者是否能安全处理重复事件？
• 重试是否区分临时异常与永久异常？
• 超时后是否可以查询最终结果，而不是只能重新提交？

3. 事件与补偿检查

• 数据库提交和事件记录是否处于同一本地事务？
• 事件是否有唯一编号、业务对象编号和版本信息？
• 投递失败是否有退避、死信和人工入口？
• 消费者处理成功但确认失败时，是否仍然幂等？
• 每类业务异常是否都有明确的最终状态？

4. 数据库与运维检查

• 高频更新条件是否命中合适索引？
• 多个事务访问相同资源时，锁顺序是否统一？
• 主库切换、复制延迟和连接重建是否经过演练？
• 是否有库存、金额、余额和订单状态不变量巡检？
• 是否能够根据请求键还原一次完整业务链路？

十一、总结：真正可扩展的是“可收敛的设计”

数据库事务一致性的核心，不是把更多操作塞进一个事务，也不是简单把隔离级别调到最高，而是把必须立即成立的不变量留在短本地事务里，把可以延迟的业务事实通过可靠事件传播，把不可避免的不确定性交给状态机、补偿和对账来收敛。

我对这类系统的最终判断只有一个：发生故障后，团队能否在不直接改库的前提下，知道当前业务处于哪个状态、下一步应该执行什么、重复执行是否安全，以及多长时间必须收敛。如果这些问题没有答案，系统即使在正常流量下表现良好，也不能称为可扩展。

下一步可以从一条最容易出问题的链路开始：画出事务边界，列出业务不变量，测量锁持有时间，增加幂等键和状态日志，再模拟提交前后、消息重复和第三方超时。先让一个流程具备可观察、可重试、可对账和可恢复能力，再逐步推广到其他模块。扩展能力不是拆出更多服务，而是让每个业务事实都拥有清晰的责任边界和可靠的收敛路径。

免费注册

咨询方案

扫码咨询方案