Shopify 用 MySQL 替换 Redis 做库存预留——而且规模化运行了
Shopify 关于用 MySQL 替换 Redis 来做库存预留的工程文章，引发了围绕单一事务型数据存储与双系统设计（用 Redis 做快速计数器）之间权衡的讨论。评论者剖析了提议的 MySQL 方案——每个可预留单位一行、使用 SKIP LOCKED 以及有限缓冲区——质疑其复杂性、在类似闪购负载下的可扩展性，以及更简单的基于购物车或 Redis 的方案是否就足够。另一条讨论线批评公司大量使用 AI 生成的技术内容，并对 Shopify 的领导文化和政治立场提出担忧，一些读者表示这削弱了他们对公司工程产出的信任。
对 Shopify 领导层与文化的看法
- 几位评论者聚焦于领导层的政治立场，指称其支持极右翼议题，以及在投票和移民问题上的争议观点。
- 一些人描述了负面的工作经历：对辱骂性词汇和粗鄙行为的容忍、雇用“酷”的非技术人员，以及一种大力推动使用 AI 的文化。
- 也有人要求更多具体证据，链接到批评性媒体报道，或认为政治角度与这篇技术帖子无关。
AI 撰写的博客文章与“slop”担忧
- 许多人认为这篇工程博客文章大体上是 LLM 生成的，理由是其文风：大量使用破折号、列表化结构、口号式表达，以及诸如简短对比句之类的“LLM 味”写法。
- 有人觉得它可读且信息量足；也有人认为这种风格冗长、信息密度低，比人写的技术文章更难解析。
- 更广泛的不满在于，公司发布的是 AI 美化过的内容，而不是工程师自己的声音；AI 语气正在渗入人类写作。
MySQL 对比 Redis，以及向 SQL 集中
- 有些人认同用 Redis 替换：维护两个存储系统会增加复杂性，尤其当库存事实本来就存在于 SQL 中时。
- 另一些人认为 Redis 非常适合预留系统，在高并发下扩展性很好，而且可以作为库存的主系统而无需与 SQL 同步。
- 关于 Redis 的持久性和事务也有争论：一方强调它的持久化和事务特性；另一方指出在严格 fsync 下性能会下降，而且缺少 SQL 工具链。
逐单位行与 SKIP LOCKED 以及缓冲池
- 这种设计——针对每个商品/地点设置有上限的“每单位一行”缓冲，使用
SELECT … FOR UPDATE SKIP LOCKED，再配合补货任务——被一些人视为把锁竞争巧妙地分散到多行上。 - 也有人觉得 1000 行缓冲和补货机制“笨重”或是“算法味道不佳”，担心其复杂性和边界情况。
替代设计与 UX 权衡
- 提议的替代方案包括：每个购物车–SKU 一行、在结账而不是付款时预留、对放弃的购物车做后台 GC，或者使用工作流引擎/持久对象来做按商品协调。
- 批评者认为，许多替代方案仍然把竞争集中到单个聚合行上，或者需要额外系统。
- 对于何时预留库存也存在分歧：早一点（在购物车/结账时）以获得更好的 UX，还是晚一点（在付款时）以避免放弃购物车囤货和错失销售。
更广泛的架构主题
- 持续存在的争论包括：微服务 vs 单数据库的简洁性、SQL vs NoSQL，以及大型公司是否应该构建自定义数据引擎，而不是依赖 MySQL。