MongoDB 6.0分片间通信默认启用snappy压缩，但仅作用于shard-to-shard内部流量，不压缩客户端到mongos及config server元数据同步流量，且压缩率有限；真正降低跨机房带宽需聚焦减少迁移频次、缩小块大小、强制流量本地化及确保config server同机房部署。
为什么开了 snappy 还是占满跨机房带宽？
snappy 确实自动生效于 moveChunk、分布式查询结果传输等场景，但它只做「轻量级压缩」：解压快（毫秒级），压缩率却只有 zstd 的 40%～50%。更关键的是：
– 它不压缩客户端到 mongos 的流量
– 它不压缩 config server 到 mongos 的元数据同步流量（这部分虽小，但高延迟下易堆积）
– 它无法抑制因分片键设计不当导致的频繁迁移
如何验证 snappy 是否真在工作？
连接任意 mongos 执行：db.adminCommand({ getCmdLineOpts: 1 }).parsed.net.compression.compressors
确认输出包含 "snappy"（注意：这仅反映客户端连接层配置，不代表分片间实际压缩器）
再查迁移真实效果：db.serverStatus().metrics.operation.moveChunk
重点关注 bytesSent 和 bytesReceived 字段，对比迁移前后网卡流量（如 iftop -P 27018），若两者比值稳定在 0.6～0.7，说明 snappy 正常生效；若接近 0.9+，大概率是迁移了大量未压缩的 BSON 文档（比如含长字符串或二进制字段）
真正能降低跨机房带宽的实操动作
既然不能换压缩算法，就聚焦「少传」和「传得更准」：
- 禁用非必要迁移：运行
sh.getBalancerState()，若返回true且业务写入高度倾斜（如sh.status()显示某 shard 数据量超均值 3 倍），先停均衡器：sh.setBalancerState(false)，再用sh.moveChunk()手动预分配热点数据 - 缩小迁移粒度：将块大小从默认 64MB 调整为 32MB：
db.settings.update({}, {$set: {chunkSize: 32}}, {upsert: true})，减少单次迁移的数据体积（但注意：过小会导致 config server 元数据压力上升） - 强制流量本地化：为每个机房的分片节点打 tag（如
{region: "shanghai"}），再创建 zone 并绑定：sh.addShardTag("shard01", "shanghai")+sh.addTagRange("db.col", {region: "shanghai"}, {region: "shanghai"}, "shanghai")，让读写尽量落在同机房内 - 检查并清理大文档：运行
db.collection.stats().avgObjSize，若 >128KB，考虑拆分嵌套结构或改用 GridFS 存储二进制内容——snappy 对大文档压缩收益低，反而拖慢迁移线程
跨机房部署时最容易被忽略的带宽陷阱
很多人盯着 moveChunk 流量，却忘了 config server 的心跳与元数据广播也走同一条网络链路。一旦跨机房部署 config server（哪怕只是 3 节点中 1 个在异地），config.replset 的 majority commit 就会受异地延迟拖累，导致 balancer 频繁重试、日志不断重发。这种“隐性重传”不体现在 bytesSent 里，但会持续吃掉 10%～20% 的专线带宽。务必确保全部 3 个 config server 节点在同一机房。
