跨可用区MongoDB流量产生额外费用是因为云厂商对跨AZ私网流量单独计费；需用节点私网IP配置副本集、通过AZ标签+readPreferenceTags控制读流量落点，并禁用NLB作内部通信入口。
为什么跨可用区 MongoDB 流量会产生额外网络费用？
阿里云等主流云厂商对「跨可用区（AZ）」的流量计费是独立于同 AZ 内网流量的。即使所有节点都在同一个 VPC 下，只要用了不同 AZ 的私网 IP（如 10.0.1.10 和 10.0.2.10），心跳、oplog 同步、客户端读请求都会被识别为跨 AZ 流量，按 GB 计费。这不是带宽限制问题，而是账单结构决定的隐性成本。
rs.add() 时用公网域名或 NLB 地址会放大跨 AZ 流量
常见错误是把所有节点都配置成连接同一个 NLB 域名（如 mongodb-rs.internal.aliyuncs.com），而 NLB 后端未开启「跨 AZ 负载均衡」，导致流量全部打到某一个 AZ 的节点；或者更糟——NLB 开启了跨 AZ 转发，但客户端读请求仍被随机分发到其他 AZ 的 secondary，造成双向跨 AZ 流量。
实操建议：
- 禁用 NLB 或 SLB 作为副本集内部通信入口；
rs.add()必须使用各节点真实私网 IP + 端口，例如rs.add("10.0.1.5:27017") - 应用连接字符串中不要写 NLB 地址；写死 primary 所在 AZ 的节点（仅限写操作），或用
readPreference=nearest+readPreferenceTags控制读流量落点 - 检查 NLB 监听器协议：MongoDB 不支持 HTTP/HTTPS 层负载均衡，必须用 TCP 模式，且健康检查需基于 TCP 端口连通性，而非 HTTP 返回码
如何让读请求尽量不跨 AZ？
MongoDB 本身不感知 AZ，必须靠 tags + 客户端驱动配合。否则即使你物理上把三个节点分别部署在杭州可用区 A/B/C，SDK 默认可能把读请求全发给 C 区节点，哪怕应用服务器在 A 区。
关键动作：
- 初始化副本集时，为每个节点显式添加 AZ tag：
rs.add({host: "10.0.1.5:27017", tags: {az: "cn-hangzhou-a"}}) - 应用连接字符串中加入：
readPreference=nearest&readPreferenceTags=az:cn-hangzhou-a（对应应用服务器所在 AZ） - 验证是否生效：在 mongosh 中执行
db.runCommand({connectionStatus: 1})，看hosts列表里当前连接的是哪个节点的 IP；再查该节点在rs.status()中的tags字段是否匹配
oplog 同步流量无法避免，但能压缩
primary 到 secondary 的 oplog 复制是刚性流量，无法跳过，但可减少无效传输：
- 禁止在 secondary 上执行写操作（确保
slaveOk未被误开，或应用层不发写请求到 secondary） - 避免大文档频繁更新：一次更新 1MB 文档字段，oplog 记录的就是完整 BSON，不是 diff；拆成小文档或用
$set精确更新字段能显著降低 oplog 体积 - 检查
rs.printSecondaryReplicationInfo()输出中的sync lag，若长期 > 1s，说明网络或磁盘已成瓶颈，跨 AZ 延迟会被放大，此时应优先优化同步链路，而非只盯费用
真正容易被忽略的是：AZ 标签没写进 rs.conf() 就直接配 readPreferenceTags，结果驱动根本找不到匹配节点，降级为默认 primaryPreferred，读请求又回到 primary 所在 AZ —— 表面省了跨 AZ 读费，实则把所有读压力堆到 primary，反而触发 CPU 高、同步延迟飙升，形成恶性循环。
