Shopify库存预留难题：从Redis到MySQL，突破高并发交易瓶颈！

【导语在电商系统中库存预留操作至关重要。Shopify此前依赖Redis运行超卖保护系统转向统一数据库战略时面临MySQL能否扛住规模的问题。经探索Shopify实现了从Redis到MySQL的切换为高吞吐互斥场景提供了新思路。】Redis模型局限凸显Shopify原有的Redis系统中每件商品有一个quantity key预约库存执行DECR命令释放执行INCR。但预约和库存账本分别存在于两个不同的系统支付成功后更新MySQL和清理Redis无法在单一原子步骤中完成可能导致超卖或欠卖。此外Redis模型不支持多仓库库存感知还增加了单独维护一个集群的运营成本。SKIP LOCKED解锁新方案核心设计思路是“每件库存一行记录”以10件库存的商品为例新设计会有10行记录。预约3件意味着在单个事务中选取并移动3行通过将预约和库存账本保持在同一数据库获得了跨reserve和claim的ACID保证。MySQL 8.0的SKIP LOCKED特性是实现可扩展性的关键在高频预约场景下不同事务之间不会相互阻塞。同时为支撑超大规模场景维护一个有限容量的可用行池每种商品/仓库组合最多1000行。连接数成真正瓶颈在生产环境负载测试时团队发现吞吐量远低于目标但预约延迟P90可接受CPU也未满载。经分析其他业务逻辑长时间持有连接消耗了连接池导致预约成为“压垮骆驼的最后一根稻草”。清理Checkout路径后主数据库的读取减少了50%事务减少了33%。重新评估MySQL配置增加线程并发配置移除了此前未发现的瓶颈。“影子模式”平稳切换团队采用“影子模式”并行运行每次预约同时写入Redis和MySQLRedis保持为数据源。并排比较两个系统验证MySQL产生了正确的业务结果且满足性能要求后再将数据源切换为MySQL。整个切换过程逐步进行从低流量Pod开始逐步扩展到最高容量商家。编辑观点Shopify的实践表明现有数据库也能处理高吞吐工作负载解决问题需全面排查真正的瓶颈可能藏在未关注之处。