-
应立即将maxmemory-policy从allkeys-lru切回volatile-lru，但需先停写、确认内存未满，再执行CONFIGSET与REWRITE，并配合RDB恢复关键数据，否则残留无TTLkey将持续引发淘汰。
-
Redis的String类型加剧内存碎片是因为频繁SET/GET/APPEND导致jemalloc中大小不一的内存块反复分配释放，旧块无法复用而残留为碎片，表现为mem_fragmentation_ratio>1.5且used_memory_rss远大于used_memory。
-
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略：空值需设短过期并避免null值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。
-
布隆过滤器必须前置到请求入口，如Web中间件或API网关，在接触Redis或数据库前完成校验；冷启动需预热合法ID，误判率宜设为1%；空值缓存须存"NULL"字符串并设5–300秒短过期；参数校验需在网关/Controller层强校验；需监控空值占比与误判率并告警。
-
RedisBitmap更新必须用Pipeline，因单次SETBIT网络开销大，10万次独立调用耗时超8秒，Pipeline可压至300ms内，并需显式execute()提交；offset须紧凑映射，key命名要可排序，BITOP前应校验长度，回滚靠双写+原子RENAME。
-
RedisPub/Sub不适合生产实时报警系统，因其消息零持久化、无消费确认与重试机制，订阅者断线或处理失败即导致报警永久丢失。
-
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。
-
LTRIM是限制RedisList长度的唯一可靠方式，因其原子性、精准截断和内存即时释放特性；必须配合LPUSH使用，错误参数会清空列表，高并发下推荐Lua脚本保障原子性。
-
哨兵选主失败或频繁切换的根本原因是时钟偏差过大或网络单向隔离；需先用ntpstat和chronyctracking检查时钟同步，再用tcpdump验证26379端口双向通信，最后才调整哨兵参数。
-
RedisLua脚本需用原子“读-判-写”实现状态变迁，推荐HASH结构存储多字段（如status、updated_at、version），通过HGETALL/HSET原子操作，结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转，返回结构化结果便于业务判断。
-
延迟双删删的是第一次更新前删缓存、第二次更新DB后延迟再删缓存；前者防旧缓存命中，后者防主从同步期间脏读写入缓存。
-
Redis在SSD云盘上AOF重写或RDBsave卡顿，主因是文件系统磁盘屏障（barrier）强制全链路落盘，导致fsync延迟飙升；可通过mount和xfs_info检查barrier=1或data=ordered确认。
-
Redis集群参数中，cluster-enabled、cluster-config-file、cluster-node-timeout等不支持热调整，CONFIGSET看似成功实则被忽略；真正可热调的仅timeout、tcp-keepalive、maxmemory-policy等少数非核心参数。
-
Redis客户端重连易打挂新主库，因默认“失败即重试”导致连接风暴；需配置指数退避+随机抖动（如Lettuce用ExponentialBackoffRetry.withJitter）、Go端自定义DialContext重试逻辑，并控制初始延迟50–100ms、最大延迟≤3s、重试8–12次。
-
RedisPub/Sub监控需聚焦连接行为与资源消耗：用PUBSUBNUMSUB查实时订阅数，instantaneous_output_kbps和client_longest_output_list组合判断积压，connected_clients与connections_received_per_sec协同识别频繁重连。
