redis节点启动失败并报oom，根本原因可能是maxmemory未设置（返回0）、dump.rdb加载内存超限、集群选举参数不合理、大key或内存碎片率过高（>1.5），需分别清理rdb、配置maxmemory与淘汰策略、调小cluster-replica-validity-factor、purge碎片或拆分大key，并确认配置文件真实生效。
节点启动失败且日志报 OOM
直接表现是 redis-server 进程起不来，日志里反复出现 OOM command not allowed when used memory > 'maxmemory' 或系统级 Killed process redis-server。这不是 Redis 主动拒绝写入，而是 Linux OOM Killer 杀掉了进程。
此时别急着改配置重启：先确认 dump.rdb 文件是否可丢弃。如果该节点数据不关键（比如纯缓存），删掉 /var/lib/redis/dump.rdb 再启动能绕过加载阶段的内存峰值；否则必须先清理内存或扩容。
- 检查当前最大内存限制：
redis-cli config get maxmemory，若返回0，说明没设上限，这是根本原因 - 临时救急可用：
redis-cli config set maxmemory 4gb（值需小于宿主机空闲内存） - 但仅设
maxmemory不够，必须同步配淘汰策略，否则仍会 OOM
集群状态卡在 fail 状态无法自动恢复
CLUSTER NODES 输出里看到节点状态是 fail? 或 fail，但主从切换没发生——常见于 cluster-replica-validity-factor 默认为 10，导致从节点认为主节点“可能只是网络抖动”，迟迟不敢升主。
修复重点不是等它自愈，而是干预选举条件：
- 把
cluster-replica-validity-factor改成0：redis-cli config set cluster-replica-validity-factor 0 - 确保
cluster-node-timeout设置合理（通常 15000ms），过短易误判，过长恢复慢 - 手动触发故障转移：
redis-cli cluster failover（在待升主的从节点上执行） - 注意：执行前确认该从节点
slaveof指向的是已宕机的 master，否则会失败
大 key 或内存碎片导致反复溢出
即使设置了 maxmemory 和 maxmemory-policy，服务仍周期性卡顿或 OOM，大概率是单个 key 过大（如百万级 HASH）或碎片率 mem_fragmentation_ratio > 1.5。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
查问题要分两步走：
- 找大 key：
redis-cli --bigkeys（生产环境慎用，会阻塞）；更安全的方式是用redis-cli --scan --pattern "*" | xargs -L1 redis-cli memory usage抽样 - 看碎片：
redis-cli info memory | grep mem_fragmentation_ratio，>1.5 就执行redis-cli memory purge（Redis 4.0+） - 拆大 key 是治本：比如把
user:1001:profile拆成user:1001:profile:base、user:1001:profile:setting - 避免用
KEYS *扫描，改用SCAN游标分批处理
配置没生效或重启后复现
改完 redis.conf 重启，发现 config get maxmemory 还是旧值？大概率是配置文件没被正确加载，或者被运行时命令覆盖了。
关键检查点：
- 确认启动时指定的配置文件路径：
ps aux | grep redis看是否带--config /etc/redis/redis.conf - 检查
redis.conf中maxmemory行是否被注释，且前面没有其他include覆盖它 - 动态设置的参数（
CONFIG SET）不会写回文件，重启即丢失——必须写进 conf 并重启 - 集群模式下，每个节点配置要单独改，不能只改一个节点就以为全集群生效
最常被忽略的是：运维部署时用脚本生成配置，但脚本漏写了 maxmemory 字段，导致所有节点默认 0。这种问题不会报错，但会在数据增长到临界点时集中爆发。
