用 MySQL 替代 Redis 做库存预留：SKIP LOCKED、连接瓶颈与高并发设计

09/23/2026 05:57:15 | China Standard Time

Shopify 如何用 MySQL 的 SKIP LOCKED、按库存单位建模、复合主键和连接可观测性，构建可扩展的库存预留系统。

# 用 MySQL 替代 Redis 做库存预留：SKIP LOCKED、连接瓶颈与高并发设计

电商结算里最容易被低估的一步，是用户点击“完成购买”之后，系统如何保证这批商品仍然可售。

如果两个并发请求同时买走最后一件商品，就会出现超卖：商家必须取消订单、向用户道歉并承担售后成本。反过来，如果系统过度保守，把实际上仍然存在的库存判断为售罄，又会造成少卖一笔订单。库存预留系统要做的不是简单地“减一个数字”，而是在高并发、短事务和复杂履约规则下，可靠地回答一个问题：这次结算是否真的拿到了可销售的库存？

Shopify 工程团队分享了一次很有代表性的架构演进：他们原本使用 Redis 保存库存预留，后来为了统一数据库策略，尝试用 MySQL 承担同样的职责，并最终在高峰流量下达到目标。关键并不是把 Redis 的数据结构机械地搬进 MySQL，而是重新设计数据模型、锁竞争方式和连接管理方式。

本文根据这次实践，梳理其中最值得借鉴的工程方法。

## 库存预留到底解决什么问题

库存预留通常包含两个核心动作。

### Reserve：预留

支付开始时，系统从满足履约条件的库存中拿出若干单位，并设置一个较短的保留时间。只要预留有效，其他结算请求就不能再次拿到这些单位。

### Claim：确认扣减

支付成功后，系统把预留转化为库存账本上的永久扣减。支付失败、超时或用户主动取消时，预留则被释放。

可以把过程抽象为：

```text
可售库存 -> 已预留 -> 已确认扣减
       \-> 过期/取消 -> 回到可售库存
```

预留并不是最终库存账本。它更像是支付过程中的短期租约，而库存账本才是最终事实来源。两者之间如果缺乏一致性，就可能出现支付成功但库存没有扣减，或者库存已经扣减但支付失败的异常。

## 规模和正确性要求

库存系统的压力不是平均流量，而是促销、闪购和节假日形成的瞬时尖峰。Shopify 文章提到，2025 年黑色星期五期间，平台峰值达到每分钟 510 万美元销售额，峰值销售速度比上一年提高了 11%。每一个触碰库存的结算流程，都可能经过预留系统。

这类系统至少需要满足以下条件：

- 在峰值流量下持续达到吞吐目标；
- 支持多仓库库存，只从能够履约的地点预留；
- 预留和库存账本之间保持 ACID 一致性；
- 不能超卖，也不能因为竞争锁而大量误报缺货；
- 预留必须足够快，不能让支付流程长时间等待；
- 某一个热门商品的竞争不能拖垮整个数据库。

这几个要求之间存在张力：锁得越严格，正确性越容易保证，但并发度可能下降；锁得越宽松，吞吐可能提高，却容易产生竞态条件。

## 失败的直觉方案：一行记录一个数量

最直观的数据模型是每个商品、每个仓库一行：

```text
inventory_item_id | location_id | available_quantity
-----------------------------------------------------
10001             | 7           | 500
```

预留三件商品时，在事务里执行：

```sql
UPDATE inventory
SET available_quantity = available_quantity - 3
WHERE inventory_item_id = 10001
  AND location_id = 7
  AND available_quantity >= 3;
```

这种设计在低并发场景下很自然，但在热门商品上，所有请求都会竞争同一行。即使数据库能够正确串行化这些更新，锁等待也会不断累积。一个商品只剩一件时，数百个请求最终都在争抢同一条记录。

问题不只是 SQL 是否正确，而是所有并发请求的竞争粒度都被压缩到了一行。

## 核心方案：一行代表一个可预留单位

MySQL 8 提供的 `SKIP LOCKED` 改变了设计空间。与其让所有请求更新同一行数量，不如把可预留单位拆成多行：

```text
item_id | location_id | reservation_group | state
--------------------------------------------------
10001   | 7            | 882001             | available
10001   | 7            | 882002             | available
10001   | 7            | 882003             | available
```

预留三件商品时，在事务中选出三行可用记录并锁定：

```sql
START TRANSACTION;

SELECT id
FROM inventory_reservation_pool
WHERE shop_id = ?
  AND inventory_item_id = ?
  AND inventory_group_id = ?
  AND state = 'available'
LIMIT 3
FOR UPDATE SKIP LOCKED;

UPDATE inventory_reservation_pool
SET state = 'reserved',
    reservation_id = ?,
    expires_at = ?
WHERE shop_id = ?
  AND inventory_item_id = ?
  AND inventory_group_id = ?
  AND id IN (?, ?, ?);

COMMIT;
```

`SKIP LOCKED` 的含义是：如果某些行已经被其他事务锁定，当前查询跳过它们，而不是等待它们释放，再继续寻找其他可用行。

这样，不同结算请求可以同时拿到不同的库存单位，避免大量请求排队等待同一个数量行。数据库仍然负责事务和锁的正确性，但竞争从“所有请求争一行”变成了“请求分散到多个可用行”。

## 为什么不能简单地为所有库存创建一行

一行一个单位并不意味着所有库存都要永久拆成无限多行。假设某个商品有 50,000 件库存，分布在 10 个仓库，如果全部展开，就会产生 500,000 行。库存规模越大，表越臃肿，扫描和补充成本也越高。

实际方案维护的是一个有上限的可用池，而不是完整复制库存账本。每个商品和仓库组合只保留一个有界的预留池，例如最多 1,000 行：

```text
库存账本：真实数量，负责事实来源
预留池：可被并发请求快速领取的有限单位
```

预留请求消耗池中的行，后台补充进程再根据库存账本补回可用行。池的大小需要在两个目标之间平衡：

- 太小：闪购时很容易被消耗完，补充速度跟不上；
- 太大：表变大，扫描和锁管理成本增加，热点数据更集中。

1,000 并不是通用常数。应当结合商品、仓库和峰值预留速率进行测算，确保池能吸收短时突发流量，同时让补充过程在持续流量下跟得上。

## 复合主键减少锁数量

最初的原型可能会使用自增 ID 作为主键：

```sql
PRIMARY KEY (id),
KEY available_lookup (shop_id, inventory_item_id, inventory_group_id, state)
```

看起来查询索引已经存在，但 InnoDB 的锁行为可能并不理想。查询通过二级索引寻找符合条件的行，而实际记录又位于聚簇主键索引中。在特定更新路径下，一次预留可能同时涉及二级索引和聚簇索引的锁。

工程团队通过观察 `SHOW ENGINE INNODB STATUS` 等信息发现，原型中一次预留可能出现两类行锁。于是把过滤条件中的关键字段放入复合主键：

```sql
PRIMARY KEY (
    shop_id,
    inventory_item_id,
    inventory_group_id,
    id
)
```

这样，查询和更新使用的关键定位字段就在聚簇索引中，有机会把锁数量从每行两类降低到一类。高并发下，锁数量的微小变化也可能显著影响吞吐，因为每个请求都会重复执行相同路径。

这里的经验不是“复合主键一定优于自增主键”，而是：不要只看执行计划和查询耗时，还要观察数据库实际加了多少锁、锁在哪些索引上，以及一次业务操作到底造成了多少并发资源消耗。

## 真正的瓶颈：连接，而不是 CPU

迁移到 MySQL 后，团队一度遇到吞吐上限。表面现象很容易误导：

- 预留接口 P90 延迟尚可；
- SQL 查询已经优化；
- 数据库 CPU 没有打满；
- 但吞吐就是上不去。

如果只盯着 CPU 和单条查询耗时，很容易继续优化错误的方向。团队尝试把多个结算请求批量合并到一次 `SKIP LOCKED` 查询中，以减少连接使用；也把部分读流量转移到副本。但压测结果仍然解释不通。

进一步观察发现：

- MySQL 内部有线程排队；
- 排队任务集中执行时 CPU 会突然升高；
- ProxySQL 到 MySQL 后端的连接池出现耗尽；
- 连接不是被某一条慢 SQL 独占，而是被其他结算流程长时间持有。

这说明“数据库 CPU 没满”并不代表数据库可以继续接收更多请求。连接池、线程调度、事务持续时间和代理层容量都可能先于 CPU 成为瓶颈。

## 给连接增加业务归因

知道连接耗尽还不够，还要知道是谁占用了连接、占用了多久。

一个实用办法是在应用发出的 SQL 中加入业务标签：

```sql
/* conn_tag:checkout_completion */
SELECT ... FOR UPDATE SKIP LOCKED;
```

ProxySQL 或其他数据库代理层解析这个标签，并按业务流程统计连接持有时间：

```text
业务流程                  连接持有总时间
checkout_completion       38%
shipping_calculation      24%
pricing                   19%
other                    19%
```

这个指标与“哪条 SQL 最慢”不同。慢查询关注单条语句执行多久；连接持有时间关注一个业务流程从拿到连接到释放连接的整个区间。即使每条 SQL 都很快，只要事务中间执行了远程调用、复杂计算或不必要的读取，连接仍然可能被长时间占用。

可观测性应当覆盖业务调用方，而不只是数据库语句：

```text
应用业务流程 -> SQL 标签 -> 数据库代理 -> 连接持有时间 -> 数据库线程/CPU
```

这条链路建立后，团队发现库存预留并不是唯一的重度连接使用者。结算路径上的其他环节持有连接时间更长，只是它们还没有先撞到连接上限。

## 清理结算路径比继续优化预留 SQL 更有效

在定位到连接归因后，团队重新整理结算流程：缩短不必要的事务、删除重复读取，并调整部分调用顺序。最终主库读取量减少约 50%，事务数量减少约 33%。

同时，他们重新审视了 MySQL 配置。`InnoDB` 线程并发参数曾经在较早时期按照保守负载设置，随着工作负载变化，这个配置也需要重新评估。

在确认有 CPU 余量后提高线程并发能力，配合应用侧的连接清理，原本看不见的瓶颈被移除。高流量压测中，写入节点 CPU 保持在 50% 以下，读取节点 CPU 低于 16%，系统仍有足够余量。

这次排查说明一个重要问题：

> 如果延迟、CPU 和吞吐之间的关系解释不通，不要默认是 SQL 慢。先把连接生命周期、事务边界和调用方占用情况测出来。

## Redis 到 MySQL 的切换不能一刀切

即使 MySQL 设计已经通过压测，也不能直接关闭 Redis 并切换全部流量。库存是高风险业务，迁移过程本身必须具备回滚能力。

采用的方式是 shadow mode，也就是双写但不立即切换事实来源：

1. 每次预留同时写 Redis 和 MySQL；
2. Redis 继续作为生产环境的事实来源；
3. MySQL 在真实流量下构建自己的状态；
4. 对比两个系统的预留结果、过期行为和异常情况；
5. 确认正确性与性能后，把事实来源切换到 MySQL；
6. 保留 Redis 双写和 kill switch，出现异常时可以回退。

由于两个系统从切换前就持续写入，因此不存在需要一次性迁移的大量“进行中预留”。Redis 中的预留仍然会被正常兑现，MySQL 则在后台接受同样的生产请求。

最终切换采用逐步放量：先从低流量 Pod 开始，再逐渐覆盖高流量商家和高流量 Pod。每一步都观察错误率、预留成功率、连接使用、锁等待和数据库健康状况。

## 这套方案的边界

“用 MySQL 替代 Redis”并不意味着任何缓存或队列都应该放进关系数据库。这个方案成立，有几个前提：

- 预留本身是强一致业务，不只是临时缓存；
- 库存账本已经位于数据库中，需要 ACID 事务；
- 预留操作可以设计成短事务；
- 可用池大小是有界的；
- 数据库连接、锁和线程都有足够的观测能力；
- 业务能够接受数据库成为核心承载层，并为它提供容量余量。

如果系统只是需要极低延迟的非关键缓存，Redis 仍然可能是更合理的选择。如果预留池无界增长、事务持续时间很长，或者大量请求都会集中到同一商品和同一仓库，这种设计也可能退化。

## 实践中的检查清单

### 数据模型

- 是否把竞争粒度从单一数量行拆散了？
- 是否区分库存账本和短期预留池？
- 预留池是否有明确上限？
- 过滤条件是否与主键、索引设计匹配？

### 事务和锁

- 预留、状态变更和过期是否在清晰的事务边界内？
- 是否使用 `SKIP LOCKED` 避免无意义等待？
- 是否观察过实际锁数量与锁等待？
- 事务中是否包含远程调用或不必要的计算？

### 连接管理

- 是否有每个业务流程的连接持有时间？
- 是否能区分慢 SQL 和长时间持有连接？
- ProxySQL、连接池和数据库线程是否同时监控？
- 是否清理了结算链路中的重复读取和无效事务？

### 发布迁移

- 是否支持 Redis 与 MySQL 双写？
- 是否有 shadow mode 和真实流量验证？
- 是否准备了 kill switch？
- 是否按照流量分层逐步放量？

## 总结

这次库存预留系统的关键，不是简单地把 Redis 换成 MySQL，而是围绕数据库的并发特性重新设计：

- 用“一行一个可预留单位”降低热点行竞争；
- 用 `SKIP LOCKED` 让事务跳过已锁记录，减少排队；
- 用有界预留池避免按全部库存无限展开；
- 用复合主键减少不必要的索引锁；
- 用连接业务标签发现真正的连接消耗者；
- 用应用清理和数据库配置共同移除吞吐上限；
- 用双写、shadow mode 和渐进切换降低迁移风险。

更深层的经验是：高并发系统的瓶颈经常不在最显眼的地方。你可能花几周优化锁和 SQL，最后却发现真正的问题是其他业务流程长时间占用了连接。只有把业务调用、事务、连接、锁、线程和 CPU 放在同一条观测链路上，才能解释系统为什么在 CPU 尚未打满时就已经无法继续扩展。

参考：

- [We replaced Redis with MySQL for inventory reservations—and it scaled](https://shopify.engineering/scaling-inventory-reservations)
- [MySQL 8.0 SELECT ... FOR UPDATE SKIP LOCKED](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html)