跨机房的延迟账
跨机房访问会把链路 RTT 直接加到每条命令上：同城两机房之间通常是零点几到一毫秒，异地跨区则在几十毫秒量级，而一条业务请求往往要发多条 Redis 命令，延迟逐条累加。常见布局是读多写少的业务就近读副本、写路径收敛到同一区域。同步与复制链路的质量必须长期观测，否则切换时问题会集中爆发。
基本信息
| 主要成本 | 链路 RTT 逐条累加，命令越多放大越明显 |
|---|---|
| 布局策略 | 就近读副本、写路径收敛到单区域 |
| 一致性代价 | 异步复制存在跨区延迟窗口 |
| 观测项 | 跨区单向延迟、复制延迟、链路丢包 |
| 常用工具 | redis-cli --latency、ping、INFO replication |
典型使用场景
- 多机房部署：先算单位延迟预算，再决定数据放在哪里
- 读多写少：读流量导向本地副本，写集中到主区域
- 切换演练：链路质量有历史基线，才能判断是链路慢了还是服务端慢了
- 跨区调度：调度把实例放到错误区域时，延迟被放大却不易察觉
- 成本评估：跨区流量费用与延迟要一起算进方案
测量与核查
测量与核查
redis-cli -h 127.0.0.1 -p 6379 --latency # 本机到本地实例的往返
redis-cli -h 10.20.0.5 -p 6379 --latency # 跨区实例的往返，两者对比
ping -c 10 remote-dc-host # 链路层 RTT 与丢包
redis-cli INFO replication | grep -E 'master_link_status|master_last_io_seconds_ago' # 复制链路状态
redis-cli -h 10.20.0.5 -p 6379 ROLE # 确认目标实例角色，副本读别读成主布局方案对比
| 方案 | 延迟 | 一致性代价 |
|---|---|---|
| 本地读副本 | 最低 | 受异步复制延迟影响，可能读到旧值 |
| 跨区直连主库 | 多一次跨区往返 | 数据最新，延迟预算被链路吃掉 |
| 多区域双写 | 本地区延迟低 | 需要冲突处理与合并策略 |
| 就近写加跨区同步 | 写路径最短 | 同步链路的可用性成为关键依赖 |
延迟预算要按「一条请求乘以平均命令数」算，而不是单条命令的 RTT：一次请求发 10 条命令时，跨区 5 毫秒的往返就变成 50 毫秒的额外延迟。
副本读跨区却不监控链路质量时，抖动会整体推高读延迟且难以归因；把跨区单向延迟与复制延迟纳入常态监控，并准备好异常时把读流量切回主区域。