-
serverCron每100ms检查一次，仅当无RDB/AOF子进程时，才根据saveparams（dirty+lastsave）触发RDB，或根据AOF状态、大小及增长率触发AOF重写；改配置不重置计时/计数，故不立即生效。
-
空值缓存过期时间设太长会导致Redis内存耗尽。因空值key不被访问，LRU无法淘汰，且每个约占100–200字节，数量多时迅速撑满内存；安全TTL应为1–5秒，需匹配业务数据可见延迟，并配合布隆过滤器、前缀命名、LFU策略及监控告警综合防控。
-
Redis7.0的io-threads仅加速socketread/write/RESP解析，不执行命令；盲目开启或多设线程数反致延迟上升、吞吐下降，需先确认瓶颈确在IO层而非主线程或内存带宽。
-
Redis6.0+才正式支持volatile-lfu和allkeys-lfu，低版本会静默降级为LRU；需通过CONFIGGET/SET确认并热生效策略，商品Key须按粒度命名（如prod:sku:10086）并用INCR+EXPIRE维护热度，OBJECTFREQ返回0–255近似值仅适用于相对排序，不反映真实访问次数。
-
Lettuce管道中flushCommands()仅发送命令不返回结果，正确做法是先保留各操作返回的RedisFuture，再调用get()或thenApply()获取响应。
-
命中率低于75%（即keyspace_hits:keyspace_misses<3:1）时应调整淘汰策略，因缓存已无法有效分担数据库压力；需结合evicted_keys增速与keyspace_misses增速同步上升来确认问题根源。
-
可行但仅适用于轻量场景；必须用EVAL执行Lua脚本原子完成“取+删”或“取+标记”，避免LPOP+DEL竞态导致重复消费或消息丢失。
-
String类型在LRU驱逐场景下内存效率低，因其每个key和value均独立占用redisObject+SDS结构，导致对象头冗余高、驱逐粒度粗；而Hash等结构共享key对象头、支持ziplist压缩，内存利用率高40%~60%。
-
应立即将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值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。
-
RedisPub/Sub不适合生产实时报警系统，因其消息零持久化、无消费确认与重试机制，订阅者断线或处理失败即导致报警永久丢失。
-
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。
-
RedisLua脚本需用原子“读-判-写”实现状态变迁，推荐HASH结构存储多字段（如status、updated_at、version），通过HGETALL/HSET原子操作，结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转，返回结构化结果便于业务判断。
-
Redis客户端重连易打挂新主库，因默认“失败即重试”导致连接风暴；需配置指数退避+随机抖动（如Lettuce用ExponentialBackoffRetry.withJitter）、Go端自定义DialContext重试逻辑，并控制初始延迟50–100ms、最大延迟≤3s、重试8–12次。
