repl-ping-replica-period是redis 5.0+推荐的心跳间隔参数，替代旧版repl-ping-slave-period；它仅控制主节点向从节点发送ping的频率，不影响replconf ack机制，且需确认配置名、版本匹配及网络链路未拦截。
repl-ping-replica-period 根本没生效？先确认参数名和版本对不对
Redis 5.0 是分水岭：旧配置 repl-ping-slave-period 在 5.0+ 仍被兼容，但官方推荐用 repl-ping-replica-period。如果你在 6.x 或 7.x 版本里改了 repl-ping-slave-period 却没效果，大概率是参数根本没加载——新版本优先读 repl-ping-replica-period，旧参数只是“备胎”。
验证方式很简单：
- 连上主节点执行
CONFIG GET repl-ping-replica-period，看返回值是不是你设的数字 - 检查
redis.conf文件里写的是哪个参数名，别混着写（比如同时存在两个，后者会覆盖前者） - 重启后用
INFO server看redis_version，确认真实运行版本
心跳包发了，但抓不到 PING？可能是 TCP 层或中间件吞掉了
即使 repl-ping-replica-period 配置正确、主节点也按周期调用了 ping，你也可能在 tcpdump 里看不到对应流量。这不是 Redis 失效，而是网络链路做了手脚。
常见干扰项：
- 云厂商的 SLB / ALB / NLB 默认 60 秒空闲超时，会静默断开长连接——PING 包还没发出去，连接已断
- 安全组或防火墙规则只放行业务端口（如 6379），但没允许 ICMP 或忽略 TCP keepalive 探测
- 某些容器平台（如早期 Kubernetes CNI 插件）对小包（
验证方法：tcpdump -i any port 6379 -w ping.pcap 抓包后用 Wireshark 过滤 redis.command == "PING"，如果完全没命中，再查 tcpdump 是否真抓到了 Redis 流量（比如过滤 tcp.len > 0 看是否有其他 Redis 协议包）。
INFO replication 里的 lag 一直为 -1 或飙升？不是心跳问题，是 REPLCONF ACK 卡住了
lag 字段来自从节点上报的 REPLCONF ACK 时间戳，不是主节点发 PING 的响应时间。它为 -1 表示主节点压根没收到任何 ACK；持续大于 1 说明从节点发送卡顿或主节点处理不过来。
这时调 repl-ping-replica-period 毫无意义，因为：
-
REPLCONF ACK是从节点每秒固定发一次，不受该参数控制 - 如果从节点主线程阻塞（比如正在加载 RDB、执行 slowlog 命令、或磁盘 I/O 高），ACK 就会延迟甚至堆积
- 主节点
used_cpu_sys或used_cpu_user持续 >80%，也可能导致事件循环来不及处理 ACK
快速定位：redis-cli -p 6379 INFO replication | grep "master_last_io_seconds_ago\|lag"，若 master_last_io_seconds_ago 正常（lag 异常，问题一定出在从节点侧。
哨兵比主节点更早判定从节点下线？down-after-milliseconds 没对齐
Sentinel 不依赖主节点的 repl-ping-replica-period 判断从节点健康，它自己独立发 PING。但如果 sentinel down-after-milliseconds 设得太小，就会抢在主节点之前把从节点标为 sdown。
必须满足：down-after-milliseconds ≥ repl-ping-replica-period × 3
否则会出现诡异现象：
- 主节点 INFO 显示
slave0:ip=...,state=online,lag=0 - 但 Sentinel 的
INFO sentinel里该从节点状态却是sdown - 触发不必要的故障转移，甚至选一个 lag 很大的从节点升主
生产环境建议：设 repl-ping-replica-period 为 30 秒，则 down-after-milliseconds 至少设为 90 秒；跨可用区部署时，这个差值还要再加缓冲。
真正让心跳“失效”的，往往不是参数本身，而是它和其他机制（TCP 层、Sentinel、从节点负载）之间的节奏错位。调一个值前，先看清楚谁在发、谁在收、谁在判——否则改了等于没改。
