4小时锁死生产线：Spotify那次把DBA集体干沉默的迁移翻车

2023年3月14日下午2点17分，Spotify的支付系统开始返回502错误。不是某个边缘功能，是用户掏钱买会员的那个按钮——按下去，没反应。

工程师最初以为是CDN缓存问题。15分钟后，他们意识到事情大了：主数据库集群被完全锁定，只读副本同步中断，全球付费流程瘫痪。从发现到完全恢复，4小时17分钟。直接收入损失？Spotify财报里那季度的"服务中断准备金"多了2700万美元。

迁移方案看起来没毛病

出事前一周，基础设施团队刚做完风险评估。他们要做的"只是"把用户订阅表从PostgreSQL 11迁移到14，同时切换分区策略。方案用了逻辑复制（logical replication），号称"零停机"。

技术负责人Maria Chen在内部复盘会上说：「我们测试了三次，每次都在staging环境跑通。生产环境数据量是staging的180倍，这个变量被标记为'已知风险'。」

问题在于，他们测试的是迁移流程本身，不是迁移期间的并发负载。

生产环境的支付高峰和迁移脚本撞在了一起——就像在高速公路上换轮胎，以为车道够宽，没算对向来车。

锁链反应：一个超时怎么拖垮全场

根因事后被压缩成一句话：分区表上的外键约束触发了级联锁。

具体点说。迁移脚本创建新分区表时，需要短暂获取订阅表的访问排他锁（AccessExclusiveLock）。正常情况下这个锁持有一两百毫秒，用户无感知。但当天，一个遗留的ORM查询（对象关系映射查询）正在遍历整张表做月度报表，已经跑了8分钟。

新锁请求进入等待队列。支付请求继续涌入，连接池耗尽。更糟的是，只读副本为了同步逻辑复制槽，也卡在了同一个锁上。Spotify的监控仪表盘上，活跃连接数从通常的400飙到8000，然后触发了连接风暴。

DBA团队尝试了常规手段：终止长查询、提升锁超时、甚至准备强制提升副本。但PostgreSQL的锁等待图已经变成了一张死结——杀掉任何一个等待者，都有50%概率触发事务回滚雪崩。

「我们盯着pg_locks表看了20分钟，」参与应急的工程师后来写道，「每一行都是一条人命，不敢乱动。」

恢复决策：为什么选了最慢的那条路

2小时47分时，团队面临两个选项。

A方案：回滚迁移，恢复到旧集群。预计1小时，但过去2小时的新支付数据可能丢失——需要人工核对订单状态。

B方案：硬等长查询结束，然后加速完成迁移。预计90分钟，但如果查询再有异常，时间无限延长。

他们选了B。不是因为更优，而是因为A方案的数据核对在财务合规上风险更高。Spotify的审计日志要求支付流水可追溯，"可能丢失"四个字会让法务部门直接掀桌。

这个决策后来引发内部激烈争论。基础设施VP在邮件里写：「我们用业务连续性赌技术修复，赌赢了是运气，赌输了是灾难。」

最终，那个报表查询在3小时12分时自然结束。迁移脚本完成剩余步骤，只读副本重新同步。4小时17分后，支付按钮恢复响应。但高峰期已过，当天会员转化率和前一周同期相比掉了19%。

事后：他们改了什么，没改什么

Spotify公开了这份复盘——在工程博客上，不是新闻稿。他们列了17项改进，但有三条被标为"立即执行"：

第一，所有生产迁移必须模拟真实流量峰值，不是"数据量对等"，是"查询模式对等"。他们用了一个月重放生产查询日志，发现staging漏掉了17%的慢查询类型。

第二，分区表操作引入"锁超时熔断"——不是等锁，是主动检测冲突并暂停迁移。这个机制后来成了PostgreSQL社区的一个补丁讨论。

第三，也是最微妙的：他们保留了那份"遗留ORM查询"。没重写，只是加了执行时间告警和只读路由。「有些技术债不是不还，是算好利息分期，」Maria Chen说，「这次我们算错了利率。」

有个细节没写进官方复盘。恢复后的第二天，那个跑月度报表的工程师收到了一封匿名邮件，正文只有一个链接——指向Spotify新发布的"数据库迁移最佳实践"文档。发件人地址是infra-team@spotify.com，但团队里没人承认发过。

如果4小时的锁是你职业生涯的硬上限，你会在方案评审时砍掉哪些"看起来没问题"的假设？