我们如何迁移Vercel每次构建背后的数据库
内容提要
Vercel将构建预热池的状态从Redis迁移到DynamoDB，以解决数据持久性问题。迁移分阶段进行，包括双写和影子读取验证。过程中遇到两次故障，并发现供应循环因延迟增加而停滞，最终通过并发设计修复。迁移成功，状态现存储于持久化数据库，循环不再依赖单次读取。
延伸解读
迁移的真正难点：隐性假设
文章指出，迁移的难点不在于数据复制，而在于发现并重构基于旧存储性能的隐性假设。例如，供应循环中的N+1查询模式在Redis毫秒级延迟下被掩盖，而DynamoDB的延迟暴露了这一问题。这提醒我们，技术选型时不仅要考虑功能，还要审视代码中可能隐含的性能依赖。
分阶段迁移与验证策略
Vercel采用了双写、影子读取等分阶段迁移策略，并通过仪表盘监控匹配率、延迟等指标来指导每个阶段的推进。这种渐进式方法降低了风险，并能在问题出现时及时回滚。对于关键系统的迁移，这种谨慎的验证流程值得借鉴，尤其是在无法停机的情况下。
故障案例的启示
迁移过程中遇到的两次故障揭示了监控盲区：一次是影子读取的额外负载导致生产故障，另一次是供应循环的延迟问题未被现有指标捕获。这强调了监控不仅要覆盖系统健康，还要覆盖迁移本身带来的影响，以及那些不在请求路径上的后台逻辑。
Q&A
Vercel为什么将构建预热池的状态从Redis迁移到DynamoDB？
因为Redis被用作临时缓存，存储了构建预热池的状态，包括令牌、容器状态和计费映射。其中计费映射无法重建，而Redis的持久性不足，存在数据丢失风险。为了确保状态持久化，Vercel决定迁移到DynamoDB。
Vercel在迁移过程中采用了哪些阶段？
迁移分为五个阶段：Redis-only、双写、影子读取、DynamoDB主读、DynamoDB-only。每个阶段都有功能开关，并尽可能保留回滚选项。
Vercel如何设计DynamoDB的表结构来替代Redis的数据结构？
以容器为中心，容器ID作为排序键，令牌作为字段存储为哈希值。状态计数使用时间感知索引，部署映射单独建表。这样大多数操作变成直接键查找，减少了复杂的数据结构操作。
Vercel在迁移过程中遇到了哪些故障？
遇到两次故障：一次是三月某区域构建中断，原因是比较机制负载过高；另一次是Redis基础设施宕机，但已迁移到DynamoDB的状态未受影响。
供应循环停滞的原因是什么？Vercel如何解决？
原因是DynamoDB的读取延迟比Redis高，导致循环中的每次检查变慢，形成N+1查询问题。解决方案是重新设计循环，让供应调用并发执行，避免串行等待，从而减少对单次读取的依赖。
迁移完成后，Vercel从中学到了什么教训？
教训是即使查询时间从1ms退化到15ms（P90），也可能导致系统故障。迁移过程中需要识别并修正基于旧存储性能的假设，并持续监控和调整。
