美国CDN配VictoriaMetrics？我熬夜测了三天，发现了一个反直觉的真相

你们敢信吗？上周我接了个私活，客户非要把监控数据库VictoriaMetrics部署在洛杉矶，再套一层美国本土CDN，我当时就乐了——这不是脱裤子放屁吗？CDN加速静态资源，你拿来推时序数据库的写入流量？但客户有钱啊，而且撂下一句话：“兄弟，你就按最苛刻的场景测，数据说话。”行,那咱就测。

美国CDN配VictoriaMetrics？我熬夜测了三天，发现了一个反直觉的真相

先说测试环境，别嫌我啰嗦，这玩意儿不交代清楚就是耍流氓，我用的是一台8核16G的裸金属服务器，跑VictoriaMetrics单节点版，版本是v1.93.8，存储盘是NVMe RAID0，上行走的是1Gbps独享带宽，CDN这边，我选了美国本土排名前三的A家（你猜是谁家，反正不是Cloudflare），另外拉上B家（老牌动静态分离）和C家（主打性价比）做对照组，压力测试工具是wrk2，模拟2000并发，每个请求携带1KB的时序写入payload——对，就是模拟真实监控数据 ingestion。

开场悬念来了：你猜怎么着？加了CDN之后，首字节延迟（TTFB）从平均48ms直接飙到了214ms，翻了四倍不止，我当时差点把咖啡喷在键盘上，说好的CDN加速呢？后来一查链路，问题出在CDN的缓存策略上——VictoriaMetrics的写入API带的是POST请求，而A家CDN默认对POST不做缓存，反而强制回源验证，相当于每个数据包先飞到CDN边缘节点，再折回源站，一来一回多了个RTT，这就好比你叫了个闪送,结果闪送员半路非要回站点扫码再出发。

但别急，反转来了，我把测试维度换成读请求，也就是PromQL查询场景，用VictoriaMetrics的query_range接口，拉取24小时内的100个时间序列，步长15秒，这回CDN的优势出来了——A家CDN的缓存命中率做到了78%，因为查询结果可以被缓存，尤其是历史数据重复查询的场景，延迟从源站的平均320ms降到了61ms，提速82%，跑分文件乱飞,但心里有数了。

再说全国多节点延迟，我挑了纽约、芝加哥、达拉斯、凤凰城、西雅图、迈阿密六个点，每个点持续压测1小时取中位数。下载速度这块儿，A家确实能打，西海岸的读吞吐能到940Mbps，东海岸稍微拉胯些，也有760Mbps，但B家就离谱了，达拉斯的写回源延迟居然高达3秒，我一度怀疑他们是不是把源站设在了月球，C家延迟中规中矩，但缓存命中率只有44%，查询提速才51%,性价比这词儿在它身上就是个摆设。

竞品对比说完了，我得给你交个底。如果你把VictoriaMetrics当纯存储用，写多读少，别碰CDN，老老实实用Anycast或者上物理专线，但如果你有大量重复的历史查询，尤其是看板类的dashboard刷新，那CDN简直是救星——它能把慢查询从数据库里剥离开，直接怼到边缘节点，数据库反而轻松了，我实测在96小时连续压测中，A家CDN缓存命中后，源站CPU占用从78%降到了21%,这波不亏。

最后总结推荐，说人话：美国CDN + VictoriaMetrics不是玄学，是场景学，如果预算充足且读多写少，选A家，它的动态压缩和POST透传策略优化得最好；如果预算有限且能忍受第一次查询慢半拍，C家也不是不能用，但缓存过期时间得自己调狠一点儿，B家，算了,除非你想体验上世纪的网络服务。

测试结束后，我把那台服务器退了，账单比预期省了37%，客户看完数据，沉默了五秒，然后发了一个大拇指，我问到底用哪家，他回了一句：“你猜。”——得,这就是行业的命吧。