Shopify 用 MySQL 替换 Redis 做库存预留：真正的瓶颈不是数据库
作者：林岚｜OC 开发者生态编辑
作者：林岚｜OC 开发者生态编辑
Shopify 在工程博客中披露，公司已经把结账环节的库存预留系统从 Redis 迁移到 MySQL，并在 2025 年黑色星期五的真实流量中完成验证。
一句话结论：这不是“MySQL 打败 Redis”，而是 Shopify 发现库存预留首先是一个需要跨步骤保持一致的事务问题；当数据模型、锁和连接池都设计正确时，少一个分布式状态源比多一个看起来更快的缓存更重要。
库存预留发生在买家点击付款之后、支付真正成功之前。系统要短暂锁住商品，避免两个买家同时买走最后一件；支付成功后再把预留变成正式扣减。做慢了会拖住结账，做错了则要么超卖，要么把还有库存的商品显示成售罄。
原系统用 Redis 的 DECR 和 INCR 处理并发并不困难。问题在于，预留状态在 Redis，正式库存账本在 MySQL。支付成功时，系统既要修改 MySQL，又要清理 Redis，但两套数据库无法放进同一个本地事务。只要中间一步失败，就可能出现钱收到了但库存没扣，或者库存扣了但预留还没释放。
Shopify 的新方案没有把所有数量塞进一行。它把每个可售库存单位建成一行，再用 MySQL 8 的 SELECT ... FOR UPDATE SKIP LOCKED 取得尚未被其他事务锁住的行。预留三个单位，就在一次事务中移动三行。MySQL 官方文档也明确说，SKIP LOCKED 会跳过已锁定记录，适合多个会话并发消费队列式表，但它返回的并不是一致视图，因此不适合随意套在一般查询上。
一行一个库存，会不会把表撑爆
会，所以 Shopify 没有把商家的全部库存都展开。每个“商品与地点”组合只维护最多 1000 个可预留行，后台持续从库存账本补充。极端抢购耗空池子时，由一个事务负责补货，其他请求等待，避免同时插入造成惊群。
工程细节比数据库品牌更关键。团队把过滤字段放进复合主键，减少二级索引和聚簇索引的重复加锁；把相关事务从默认的 REPEATABLE READ 调整到 READ COMMITTED，绕开空池补货时的间隙锁；统一多张表的加锁顺序，减少死锁；购物车多商品则用 UNION ALL 合并往返。
但上线压测后，真正限制吞吐量的不是查询，也不是 CPU，而是连接。Shopify 给 SQL 加上业务调用方标签，并在 ProxySQL 汇总连接持有时间，才发现结账链路的其他代码长期占用连接。清理之后，主库读取量减少 50%，事务数减少 33%；高流量闪购中，写库 CPU 仍低于 50%，读库低于 16%。
这解释了为什么“换数据库”常常只是故事的前半段。单条查询很快，不代表整条业务链路能扩展。连接池、事务边界、锁顺序和旁边服务的行为，可能比 SQL 本身更早把系统压垮。
这意味着可以删掉 Redis 吗
先别急着激动。Shopify 迁移的是一种特定工作负载：短事务、强一致、有限数量的互斥领取，而且库存账本本来就在 MySQL。Redis 仍然适合缓存、限流、短期状态和对延迟极敏感但允许其他一致性方案的场景。
真正可复用的经验是重新核算系统边界。五年前为了性能拆出的专用存储，在数据库能力和硬件变化后，可能已经不再值得承担双写、补偿和运维成本。反过来，如果把所有流量重新塞回关系数据库，却没有观测锁、连接和事务持有时间，只是把分布式故障换成集中式故障。
Shopify 也没有直接切换。它先让 Redis 和 MySQL 双写，以 Redis 继续作为事实来源，对比真实生产结果；确认正确性和吞吐量后，再按低流量到高流量逐步切换，并保留回退开关。这套迁移方式，比“我们压测通过了”更值得抄。
关键事实
- Shopify 称 2025 年黑色星期五峰值销售额达到每分钟 510 万美元，每笔涉及库存的结账都会经过预留系统
- 新方案用 MySQL 8 的
SKIP LOCKED并发领取库存单位行，并让预留与库存账本进入同一 ACID 事务 - 每个商品和地点组合的可用行池上限为 1000，避免按全部库存无限扩表
- 团队最终发现吞吐瓶颈主要来自数据库连接被其他结账流程长期占用，而不是预留查询本身
OC 判断
这次迁移最有价值的不是技术栈站队，而是把“性能问题”重新定义成“正确性与共享资源问题”。Redis 很快，但跨 Redis 和 MySQL 的业务动作并不会自动原子化；MySQL 能扛住流量，也建立在精确的数据模型、锁策略、连接观测和渐进切换之上。
为什么重要
- 对开发者：评估缓存或专用队列时，要把补偿逻辑、双写和连接占用一起计入复杂度。
- 对架构团队：低 CPU 与高排队同时出现时，应先观察连接持有者和完整事务路径。
- 对商家：库存一致性不是后台洁癖，它直接决定超卖、误售罄和结账成功率。
评论
围绕这篇文章补充信息、提出问题或分享观察。