我们如何将 CDN 元数据查找延迟降低 91%
内容提要
Vercel CDN每秒处理超8000万次路由查询，原按路径逐个获取元数据导致大型站点缓存频繁失效。团队将元数据分组为约200KB的索引分片，一次获取即可缓存多条路径，并支持二分查找。生产测试显示P99查找延迟降低91%，平均延迟降低79%，部署速度提升约10%。
延伸解读
分片大小为何定在约200KB
文章指出，分片过大会导致LRU缓存未命中时传输成本过高，分片过小则区域缓存未命中率上升。团队通过生产测试发现约200KB的分片能在区域缓存命中率和LRU未命中填充成本之间取得平衡。这一尺寸并非理论推导，而是基于实际流量分布和缓存层级行为得出的经验值，对类似元数据查找系统有参考意义。
影子模式如何保障路由安全
由于元数据查找影响每个请求的路由结果，团队采用影子模式：在功能标志后，对随机样本同时执行新旧两种查找，但仅返回旧结果，并在后台比较差异。这种方式在不影响生产请求的前提下，持续数周检测不一致。影子模式还发现了一个旧编码中罕见的emoji分割bug，验证了新格式的鲁棒性，为安全切换提供了信心。
更小分片为何未被采纳
团队评估了三种压缩方案：前端编码、去重元数据的JSONL文档、自定义紧凑序列化。离线模拟显示这些方法能显著减小分片体积，但预测的延迟收益有限。考虑到额外的编码、兼容性和部署工作，团队认为不值得为此迁移。这一决策体现了在性能优化中权衡投入产出比的原则，也为未来其他工作负载保留了优化空间。
部署速度提升的连带效应
分片元数据上线后，团队移除了构建管道中冗余的步骤：跳过逐路径元数据上传节省约9.7秒，将路由组元数据写入清单节省约4.5秒，不再上传空文件节省约2.4秒，合计约16.6秒。整体部署步骤提速约10%，对于元数据密集的部署，估计接近25%。这表明优化查找路径的同时，也能简化构建流程，带来额外收益。
Q&A
Vercel CDN 的元数据查找延迟降低了多少？
P99 延迟降低了 91%，平均延迟降低了 79%。
为什么 Vercel 要改变元数据查找方式？
因为原来按路径逐个获取元数据，导致大型站点缓存频繁失效，每次新部署都会产生新的缓存键，造成重复的缓存未命中成本。
什么是分片（shards）？
分片是将多个路径的元数据分组存储的文件，每个分片大小约 200KB，一次获取即可缓存多条路径的元数据，并包含索引以支持二分查找。
如何确定分片的最佳大小？
通过生产测试发现，约 200KB 的分片大小能在区域缓存命中率和 LRU 未命中成本之间取得平衡，使 P99 延迟降低 91%。
分片如何实现快速查找？
分片使用排序的 JSONL 记录和内联索引，通过二分查找定位路径，只需解析匹配的元数据值，无需解析整个分片。
部署速度提升了多少？
部署步骤整体快了约 10%，对于元数据密集的部署，估计提升接近 25%。
如何确保新路由方式的安全性？
通过离线测试和影子模式（shadow mode）在生产环境中对比新旧查找结果，确保一致性，并发现和修复了旧编码中的罕见 bug。
