-
RedisSentinel进程挂了由systemd兜底重启，因其默认可用、配置简洁、日志集成好；需配置Restart=always、明确--sentinel参数、检查端口绑定、配置语法及目录权限，并通过redis-cli验证哨兵实际工作状态。
-
要定位被淘汰的key，需监控evicted_keys增量、expired_keys飙升情况，并结合Redis7.0+的MEMORYUSAGE与OBJECTFREQ抽样分析；allkeys-lru不安全，应优先用volatile-lru/lfu；LFU更耗CPU因频次衰减更新；验证key是否频繁淘汰可用PFADD+PFCOUNT埋点统计。
-
根本原因是COW导致RSS内存暴涨触碰maxmemory上限而被迫淘汰；bgsave时fork子进程触发Copy-On-Write，父进程修改内存页即复制物理页，临近maxmemory时瞬时内存增长直接触发淘汰。
-
volatile-lru是仅在带TTL的key中按LRU算法驱逐的内存淘汰策略，不处理未设置过期时间的key；会话key必须显式设置TTL，否则成为永生key导致内存溢出。
-
notify-keyspace-events开启后会显著增加CPU开销，因其在每个命令执行后强制执行事件广播逻辑，即使无人订阅；高写入场景下DEL、EXPIRE、SET等操作均触发线性增长的事件生成与分发。
-
不能直接升级所有节点内核，因内核版本差异会导致epoll行为、transparent_hugepage策略、net.core.somaxconn等参数不一致，引发连接拒绝、延迟毛刺或集群握手失败。
-
maxclients作用于每个Redis实例（节点）而非整个集群，集群中6个节点需单独配置；其实际生效值取配置值与系统ulimit-n的较小值，且slave节点因承担复制和读请求双重压力更易触顶。
-
缓存击穿需用Redis原子命令SETkeyvalueEXsecondsNX加key级互斥锁，配合Lua脚本安全解锁；推荐RedissonRLock自动续期，空值缓存需权衡数据一致性与性能。
-
磁盘满是配置失当与监控缺位导致的事故信号，表现为RDB写入失败、AOF重写卡住等错误；根本原因是未限maxmemory、AOF重写阈值过松、过期键堆积及数据与日志混放同一分区。
-
内存淘汰不会触发invalidation消息，因其是后台异步驱逐，不走命令执行路径，tracking模块无法感知；只有DEL、SET、EXPIRE等显式变更命令才会触发。
-
AOF重写期间used_memory_rss突然翻倍，根本原因是Redis启用双缓冲机制并触发COW大量页复制。主进程同时维护新旧AOF缓冲区，大Key修改或哈希扩容导致RSS飙升1.5–2倍，OOMkiller可能介入。
-
调大hash-max-ziplist-entries内存不降反升，因ziplist启用需同时满足entries、value长度及数据紧凑三条件；单个value超hash-max-ziplist-value即退化为hashtable。
-
dump.rdb文件越积越多是因为Redis默认不自动清理旧快照，每次bgsave生成新文件但保留旧文件，需依赖外部脚本按时间戳安全清理。
-
volatile-ttl是Redis唯一支持按剩余过期时间优先淘汰的策略，仅作用于ttl>0的已设过期键，每次内存不足时淘汰一个最接近到期的key，非批量清理、不主动扫描、不保证全量精确排序。
-
单纯用EXPIRE挡不住缓存击穿，因Redis物理过期会删除key导致并发请求全打到DB；逻辑过期通过value内嵌expireTime时间戳由应用判断数据有效性，配合长TTL防key被清，再用SETNX避免重复更新。
