HDUO Lab

深入跨区多活陷阱排查：就近路由穿透引发的专线雪崩与 Redis 复制环路实战

作者：

ningniu

在

跨区双活架构中，依赖软路由的“故障转移”一旦脱离物理带宽管控，极易引发灾难。排查某次 P99 从 20ms 飙升至 2000ms 故障时发现：Istio 就近路由因探测失败将流量跨专线打向对端，瞬间吃满 10Gbps 带宽。专线拥塞导致底层 Redis 跨区复制 TCP 超时断开，继而反复触发全量 RDB 同步，形成带宽挤兑死锁。核心结论：多活架构的故障域隔离必须是硬性的，严禁在无 QoS 限制下跨区降级重试。

现场还原：从网关 P99 毛刺到专线 BGP 路由黑洞

近期监控系统抛出大规模告警，A 机房的 API 网关 99 线出现剧烈抖动，同时伴随大量 503 Service Unavailable 和 upstream connect error or disconnect/reset before headers。

登录 A 机房的网关节点，第一反应是看系统负载和网络状态：

# 检查网络连接状态和重传率
$ ss -nti | grep -E 'ESTAB.*10.20.' # 10.20.x.x 为 B 机房网段
ESTAB      0      0       10.10.5.10:45123   10.20.8.50:8080
     cubic wscale:7,7 rto:235 rtt:25.4/4.2 mss:1460 cwnd:10 ssthresh:8 bytes_acked:15432 bytes_received:4213 segs_out:34 segs_in:32 data_segs_out:12 data_segs_in:10 send 4.6Mbps lastsnd:2 lastrcv:2 lastack:2 pacing_rate 5.5Mbps delivery_rate 3.2Mbps retrans:1/15 reordering:3 rcv_space:29200 rcv_ssthresh:29200 minrtt:21.1

核心指标刺眼：rtt:25.4/4.2（平时同城跨区专线 RTT 在 1.5ms 左右，现在飙到了 25ms），且存在大量 retrans (重传)。

接着调出 Prometheus 对交换机端口的流量监控，发现连接 A、B 机房的 10Gbps 物理专线出向带宽在 1 分钟内被打成了直线（100% 饱和）。专线被打满，导致底层网络开始疯狂丢包，BGP 甚至出现了短暂的 Keepalive 超时（Hold Time Expired），造成局部路由黑洞。

问题明确：A 机房内产生了巨大的跨区突发流量，吃干了专线。

为什么 Istio 的原生就近路由会成为“专线杀手”？

在双活架构（Active-Active）中，标准的做法是“单元化闭环”或“就近路由（Locality Load Balancing）”。业务流量进入 A 机房后，全链路 RPC 应该在 A 机房内闭环。

检查 Istio (版本 1.18) 的 DestinationRule，业务为了实现高可用，配置了基于异常点检测（Outlier Detection）的跨区故障转移（Failover）：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-service-dr
spec:
  host: order-service.default.svc.cluster.local
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 100 # 致命配置
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
          - from: cn-east-1a
            to: cn-east-1b

触发机制解析：

  1. A 机房的 order-service 某几个 Pod 因 GC 停顿或局部 CPU 争抢，导致处理耗时增加，触发了 3 次 5xx 或超时。

  2. Envoy 的 Outlier Detection 将这些 Pod 踢出负载均衡池。

  3. 由于 maxEjectionPercent: 100，A 机房的所有 Pod 极易被相继踢出（雪崩效应）。

  4. 触发 Locality Failover 策略，Envoy 将原本属于 A 机房的数万 QPS 流量，100% 跨专线转发到了 B 机房 (cn-east-1b)。

在 10Gbps 专线中，平时只跑 1-2Gbps 的基础数据同步。突发的 HTTP/RPC 流量瞬间占据了 8Gbps 以上，打满了硬件队列。

衍生灾难：数据一致性取舍与底层 Redis 复制雪崩

专线被打满只是表象，真正让系统陷入长达半小时假死的，是底层数据同步机制的崩溃。

我们的 Redis 集群（基于 KeyDB 6.3 版本构建的多活双向同步架构，Active-Replica）依赖专线进行 A/B 机房的数据实时同步。当专线被 RPC 流量挤占，丢包率达到 15% 时，Redis 层面发生了灾难性的连锁反应：

  1. 连接超时断开：KeyDB 双向同步的 TCP 连接因大量丢包，超过 repl-timeout (默认 60s) 断开。

  2. 复制积压缓冲区溢出：专线断开期间，A 机房依然有局部写入，但同步发不出去，repl-backlog-size (配置为 512MB) 迅速被打满。

  3. 陷入全量同步死锁（Full Sync）：当专线稍微恢复，A、B 机房的 KeyDB 尝试重连，发现增量偏移量 (offset) 已经对不上，只能发起全量同步 (BGSAVE)。

  4. 带宽绞肉机：几十 GB 的 RDB 文件开始通过专线传输，彻底杀死了专线仅剩的带宽。RPC 降级流量和 RDB 传输互相抢占带宽，TCP 拥塞控制形同虚设，导致系统彻底瘫痪。

排查时查看 KeyDB 日志，满屏的同步失败：

34123:M 12:45:01.123 # Connection with replica 10.20.5.6:6379 lost.
34123:M 12:46:15.456 * Partial resynchronization not accepted: Replication backlog is too small.
34123:M 12:46:15.456 * Starting BGSAVE for SYNC with target: disk
34123:M 12:48:10.789 # SYNC failed. Can't write to replica: Connection timed out

架构修正：防御性多活设计的落地

高可用多活的核心不是“无脑重试和漂移”，而是故障域隔离。为了防止此类跨区雪崩，必须做以下改造：

1. 收敛跨区 Failover 权限，限制逃逸爆炸半径

严禁在业务 RPC 层开启 100% 的跨区容灾。修改 Istio DestinationRule，将 maxEjectionPercent 压制在 20% 以下，并在 Envoy 层熔断跨区流量带宽。若 A 机房真挂了，应该在最外层流量调度（如 DNS/GSLB 或边缘网关）切流，而不是在内网微服务层横向穿透。

2. 在网络 QoS 层面进行硬隔离 (tc / cgroups)

专线带宽不能让应用层随意抢占，必须为底层的 DB/KV 数据同步预留保障带宽。通过 Linux tc (Traffic Control) 在出海网关上打标记：

# 为 6379 端口 (Redis 跨区同步) 保留 3Gbps 绝对高优先级带宽
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Gbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 3Gbit ceil 5Gbit prio 1 # DB 同步
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 5Gbit ceil 8Gbit prio 2 # RPC 流量
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 6379 0xffff flowid 1:10

3. 调优 Redis/KeyDB 同步参数，避免频繁 Full Sync

针对专线可能存在的抖动，放大复制缓冲区，增加抗抖动容忍度：

# redis.conf 核心调优
repl-timeout 120                   # 容忍更长时间的网络拥塞丢包
repl-backlog-size 4096mb           # 扩大 backlog，确保断连期间增量数据不被覆盖
client-output-buffer-limit replica 8192mb 4096mb 180  # 避免同步期间 buffer 撑爆导致连接被强制 kill

常见问题 (FAQ)

Q1：多活架构中，微服务调用到底该不该跨机房 Failover？ A： 尽量不要。多活架构的黄金法则是“本域内聚，闭环调用”。一旦发生服务雪崩，跨区 Failover 通常会把对端机房也打垮（连环爆炸）。正确的做法是：直接熔断失败的请求，向上抛出错误，通过外部接入层（如 CDN 或 API 网关）将该用户的流量整体调度到健康的机房，确保上下文都在同一个数据中心。

Q2：异地双活场景下，Redis 如何处理跨机房双写冲突导致的脏读？ A： 这是数据一致性取舍问题。如果没有类似 CRDT（无冲突复制数据类型）的底层支持，纯靠应用层双写几乎必踩坑。实战中，一般通过“按用户 ID 或租户路由（Sharding）”来保证同一个实体同一时间只在一个机房活动。如果发生底层同步延迟，应用层必须容忍最终一致性，或在关键操作（如扣费）时降级回源到主库。

Q3：当专线拥塞导致数据库同步延迟过大，如何避免业务读到脏数据？ A： 必须在基础架构层面暴露同步延迟指标（如 MySQL 的 Seconds_Behind_Master 或 Redis 的 master_repl_offset 落差）。当延迟超过阈值（如 500ms），中间件层应当自动将该机房的只读请求强制路由到主节点（即便牺牲 RT），或者将该机房在全局 GSLB 中标记为下线，防止业务大面积读取到历史态数据。

更多文章