挑战在结账时买家点击“完成购买”Shopify 需确保他们所购商品仍有库存。若判断失误可能出现两种情况一是两位买家购买同一商品的最后一件商家需取消一个订单发送道歉邮件并承担售后成本二是告知买家商品已售罄但实际仍有库存商家损失一笔交易。在 2025 年黑色星期五其平台上的商家每分钟销售额峰值达到创纪录的 510 万美元每一笔交易都涉及库存操作。Shopify 的超售保护系统多年来基于 Redis 运行转向统一数据库策略时面临 MySQL 能否处理同样规模业务的难题。此前尝试失败MySQL 8 的 SKIP LOCKED 特性带来新思路受 37signals 启发Shopify 基于 MySQL 重建库存预留系统并在 2025 年流量高峰达高吞吐量目标。挑战详情什么是超售保护超售保护主要有两个操作预留支付开始时将商品标记为已预留确认支付成功后从库存总账中永久扣除相应数量商品。结账流程依赖这些操作的快速和准确性否则会导致超售或欠售。规模和正确性要求Shopify 支撑着美国超过 14% 的电子商务业务2025 年黑色星期五每分钟销售额峰值较前一年增长 11%。系统需在流量高峰支持高性能吞吐量目标考虑多地点库存确保 ACID 特性杜绝超售和预留失败。Redis 模型及其局限性之前系统将预留信息存于 Redis通过 DECR 和 INCR 实现预留和释放。但预留信息和库存总账分存两系统确认步骤无法原子操作可能导致超售或欠售且不支持多地点库存管理增加运营成本。将预留信息迁移到 MySQL 可避免这些问题。解决方案SKIP LOCKED核心思路每个可售单位一行记录设计上有上限Shopify 为每个可售单位创建一行记录通过将预留信息和库存总账存于同一数据库实现 ACID 特性。SKIP LOCKED 可避免并发冲突但大规模场景下为每个单位创建一行会使查询变慢因此为每个商品/地点组合维护上限为 1000 行的可用行池。该上限根据限时促销期间峰值预留率确定若池耗尽会触发补充操作。关键技术决策1. 复合主键减少每行的锁数量第一个原型用自增 ID 作主键每次预留操作产生两个行锁。改为复合主键后每行只需一个锁索引和主键设计影响锁数量和系统吞吐量。2. 读已提交隔离级别避免间隙锁上确界锁执行 SELECT ... FOR UPDATE SKIP LOCKED 时会出现间隙锁可能导致死锁。将事务隔离级别从 REPEATABLE READ 改为 READ COMMITTED 可避免此问题。3. 一致的锁顺序避免死锁预留和确认操作以不同顺序访问两个表会导致死锁统一操作顺序可避免。4. 使用 UNION ALL 进行批量操作使用 UNION ALL 对预留查询进行批量处理可减少交互次数降低高负载下的延迟。真正的瓶颈连接数而非 CPU生产环境中系统吞吐量低于目标值尝试批量处理预留请求、转移读操作负载后问题仍存在。负载测试中观察到 MySQL 线程排队、CPU 使用率飙升、ProxySQL 层与 MySQL 后端连接耗尽。通过添加注释标签和跟踪功能发现结账流程其他部分长时间持有连接清理结账流程和重新审视 MySQL 配置后消除了吞吐量上限。切换过程Shopify 采用“影子模式”同时运行 Redis 和 MySQL 系统验证 MySQL 性能后将真实数据源切换到 MySQL可快速切换回 Redis切换过程逐步进行。收获一是要重新审视旧决策新特性使之前无法实现的事变得可行配置也需随工作负载和硬件变化重新检查二是从小处着手并观察简单原型和快速反馈循环更有效。现在 MySQL 能处理曾认为需专门基础设施的工作负载。Shopify 相关资源解决方案包括起步、销售、营销、管理等方面的多种解决方案及对应链接。定价[定价](https://www.shopify.com/pricing)资源包括帮助与支持、热门话题、必备工具等方面的资源及对应链接。最新动态更新日志和新闻室的链接。还有工程博客、人工智能与机器学习等相关主题链接以及搜索、登录、免费开始等入口。可在任何地方为 Shopify 工作提供查看开放职位链接。介绍 Shopify 的关于我们、职业发展等多方面信息及对应链接。介绍支持、开发者、产品、全球影响等方面的信息及对应链接以及服务条款、隐私政策等内容。