根本原因是Redis内存溢出导致主库进入只读状态，Sentinel因无法执行INFO等探测命令而误判主节点下线；当used_memory逼近maxmemory且淘汰策略为noeviction时，写命令直接报OOM错误，触发异常切换。
为什么Sentinel主从切换会因Redis内存溢出失败
根本原因不是Sentinel本身挂了，而是它依赖的Redis实例在OOM时进入只读或拒绝写入状态，导致Sentinel无法执行INFO、CONFIG GET等探测命令，误判主节点下线。更隐蔽的是：当主库used_memory逼近maxmemory且淘汰策略为noeviction时，写命令直接返回(error) OOM command not allowed when used memory > 'maxmemory'，Sentinel发心跳失败后触发误切。
检查Sentinel是否被OOM连带影响
先确认Sentinel进程自身是否健康，再排查它连接的Redis实例：
-
redis-cli -p 26379 ping—— 看Sentinel是否响应 -
redis-cli -p 26379 sentinel masters—— 查主节点状态字段中flags是否含s_down或o_down - 对主库执行
redis-cli info memory | grep -E "used_memory|maxmemory|mem_fragmentation_ratio"，若used_memory == maxmemory且mem_fragmentation_ratio > 1.5，Sentinel大概率已失联
给Sentinel加一层内存保护兜底
Sentinel不管理内存，但你可以用外部机制防止它因Redis OOM而误判：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在主库配置中启用
maxmemory-policy allkeys-lru（别用noeviction），避免写入直接失败 - 设置
min-slaves-to-write 1和min-slaves-max-lag 10，让主库在从库延迟过大或掉线时主动拒绝写入，比OOM后被动崩溃更可控 - 用
redis-cli --bigkeys定期扫描，对识别出的>1MB的hash或zsetkey 加上EXPIRE，防止单key吃光内存 - 在部署层加cgroup限制：对Redis进程设
memory.max（Linux cgroup v2），比Redis自身maxmemory更硬性，避免jemalloc分配超限
修复后验证Sentinel行为是否回归正常
改完配置必须验证Sentinel能否真正感知到主库恢复，而不是卡在“半下线”状态：
- 手动触发一次
redis-cli -p 26379 sentinel failover mymaster，观察日志是否出现+switch-master - 清空主库内存：
redis-cli config set maxmemory 4gb→redis-cli flushdb→ 再config set maxmemory 8gb，看Sentinel是否重连并更新is-master-down-by-addr结果 - 重点盯
redis-cli -p 26379 sentinel sentinels mymaster输出里每个sentinel的last-ping-reply和last-ok-ping-reply时间差，超过down-after-milliseconds值就说明通信仍异常
最易被忽略的是：Sentinel默认每10秒发一次INFO，但若主库OOM后响应缓慢，Sentinel可能在超时前就重试三次，累积大量TIME_WAIT连接，最终耗尽文件描述符——所以调大tcp-keepalive和降低down-after-milliseconds要同步做，不能只改一个。
