-
根本原因是COW导致RSS内存暴涨触碰maxmemory上限而被迫淘汰；bgsave时fork子进程触发Copy-On-Write，父进程修改内存页即复制物理页，临近maxmemory时瞬时内存增长直接触发淘汰。
-
大key在Redis主从同步中会触发复制断连，表现为从库state由online突变为offline、日志反复出现Connectionwithmasterlost和Resyncingfrommaster，根源是RDB/AOF传输超时或内存溢出。
-
min-slaves-to-write是主从切换丢数据时首要排查项，它控制主节点在合格从节点不足时拒绝写入，但需配合min-slaves-max-lag和真实复制状态（state=online、lag≤阈值）才生效。
-
主从节点淘汰策略必须完全一致，否则必然导致数据不一致；需统一maxmemory-policy、maxmemory值，确保read_only开启，并避免从节点写操作及运行时配置变更。
-
Redis单个STRING超10MB必须拆分，建议512KB内切片并用GETRANGE/SETRANGE操作；BigHash应按访问频次和语义拆为小Hash，禁用HGETALL；一致性靠Lua脚本或状态字段+重试保障。
-
PUBSUBNUMSUB命令可实时获取指定频道的活跃订阅者数量，返回整数（无人订阅时为0），支持多频道批量查询，但不区分SUBSCRIBE/PSUBSCRIBE，且在RedisCluster中需直连对应节点执行。
-
INCRBY不能直接用作全局唯一ID，因其在主从复制延迟、Redis重启无持久化、分片集群跨slot等场景下会导致ID重复或跳变；可靠方案是时间戳+原子自增组合，并需开启AOF、Lua封装、slot标签等保障措施。
-
redis-check-aof不能修复截断的AOF文件，仅校验并截断末尾不完整命令，使文件回退至最后一个完整写入点。
-
OBJECTFREQ返回key的LFU近似频次（0–255），多次GET后应上升；频次非线性增长、有衰减、依赖serverCron更新，需确认Redis≥4.0、maxmemory-policy正确配置且内存压力存在。
-
Redis过期事件非实时触发，仅在键被真正删除时发布__keyevent@0__:expired消息，存在延迟且不保证100%送达；需显式配置notify-keyspace-eventsEx，SpringBoot需正确配置RedisMessageListenerContainer并指定精确频道名。
-
频道名本身不引发哈希冲突，但不良命名会损害运维、调试与权限控制；应采用小写、英文数字、下划线/点号分层的短名（≤64字符），避免空格、通配符、控制字符及动态拼接注入风险。
-
Redis内存未立即下降是因为采用惰性+定期双机制清理过期key，定期清理受hz参数控制；hz越大扫描越频繁但CPU开销越高，默认10，调至100可加速清理，超100收益递减且可能引发高CPU。
-
Redis内存淘汰策略由maxmemory-policy配置决定，不设则默认noeviction导致写入失败；需结合数据TTL、访问模式及一致性要求选择volatile-lru、allkeys-lru等策略，并确保maxmemory非零、淘汰触发条件满足。
-
Redis集群无法在入口统一配置slowlog，因其去中心化架构决定slowlog是节点级内存缓冲区，仅记录本节点命令，CONFIGSET等配置不跨节点生效，必须逐节点独立启用、采集和聚合。
-
Redis发布订阅卡顿主因是客户端消费能力不足或连接资源耗尽，而非Redis服务端性能瓶颈；需隔离连接池、改用异步驱动+批处理+超时熔断，并在需可靠性时迁移到Stream。
