跨数据中心Redis Replication与Sentinel部署的延迟影响咨询

前置场景说明 #

基于你给出的跨数据中心延迟参数：

A <> B: 5 ms
A <> C: 25 ms
B <> C: 25 ms

业务为低延迟要求的实时消息代理场景，以下为对应问题的解答：

分不同复制模式分别讨论：

• 异步复制（Redis默认模式）
  写操作延迟仅和客户端所连主节点的同DC链路有关，若主节点部署在A或B、客户端也在同DC，主节点本地处理完写请求即可返回，不会受25ms跨DC复制延迟影响。但跨DC同步会存在明确的数据滞后：A/B节点间同步滞后约5ms，A/B到C节点的同步滞后约25ms。如果业务做了读写分离，读C节点的从实例会读到25ms前的旧数据，读A/B的从实例仅有5ms的可接受滞后。另外如果主节点故障宕机，未同步到从节点的增量数据会直接丢失。
• 半同步复制（开启WAIT命令或相关半同步配置）
  写操作需要等待指定数量的从节点返回ACK后才会给客户端响应，若要求C节点的从实例也返回ACK，写延迟会直接上涨到至少25ms，不符合实时消息业务的低延迟要求；若仅要求A/B同区域的从实例返回ACK，写延迟仅会增加约5ms，大部分业务场景可接受。

额外需要注意：若跨DC链路出现抖动、丢包导致复制缓冲区溢出，会触发全量同步，25ms延迟下全量同步的耗时会远高于同DC场景，同步期间从节点无法提供稳定服务，还会占用大量跨DC带宽。

Sentinel的故障判定、脑裂规避、选主逻辑都会针对跨DC延迟做适配：

• 故障判定阈值适配：Sentinel默认的down-after-milliseconds参数为30000（30秒），你场景中的25ms最大延迟远低于默认阈值，不会出现常规状态下的误判。如果跨DC链路存在常规抖动，可以将该阈值调整为最大往返延迟的3-5倍，避免临时网络波动导致Sentinel误判节点下线。
• 脑裂规避逻辑：跨DC部署的场景下网络分区概率更高，只要将Sentinel的法定人数quorum配置为2，3个Sentinel实例分别部署在A、B、C三个DC的前提下，哪怕任意两个DC之间的链路断开，只要其中一侧能连通C节点的Sentinel就能凑够法定人数完成故障切换，不会出现两边同时选主的脑裂问题。
• 选主优先级优化：Sentinel选新主节点时默认优先选择复制偏移量最大的从节点，你的场景下A/B间同步滞后仅5ms，远低于到C节点的25ms滞后，Sentinel会优先选择A/B区域的从节点作为新主，既保证新主的数据丢失量最小，也能保证后续客户端接入的延迟符合要求。

这种部署方式反而更适配你低延迟的业务要求：

• 彻底消除了C节点的数据同步开销：主节点不需要向C节点同步全量/增量数据，跨DC带宽占用大幅降低，写操作也完全不需要考虑C节点的同步延迟，半同步复制仅需要等A/B区域的从节点ACK即可，写延迟增量仅5ms，完全满足实时消息业务要求。
• 提升Sentinel集群可用性：3个Sentinel分别部署在3个DC、quorum设为2的前提下，任意单个DC故障宕机，剩下两个DC的Sentinel仍能凑够法定人数完成故障切换，不会出现集群不可用的问题。
• 避免跨DC脏读：不需要从C节点读取数据，彻底规避了25ms同步滞后带来的脏读问题，所有读写请求都可以在A/B区域完成，端到端延迟可控制在10ms以内。

需要注意的是，C节点的Sentinel配置要和A/B节点保持一致，不要单独调大down-after-milliseconds阈值，避免真实故障发生时故障判定太慢影响恢复效率。

内容的提问来源于stack exchange，提问作者user2693017