-
@Cacheable默认不设过期时间，若统一配置TTL则所有key同步过期易引发雪崩；需通过RedisTemplate手动写入并添加随机偏移（如10分钟±60秒）来缓解。
-
Redis发布订阅不保存历史消息，因此SUBSCRIBE收不到已发布的消息；审计必须由发布端主动同步写入持久化存储，不能依赖Pub/Sub自身机制。
-
主从同步断开时repl-backlog溢出会导致全量同步反复触发；需根据写入速率与最大重连时间估算合理大小，动态调整后须同步更新配置文件。
-
Redis主从复制卡顿延迟飙升的典型表现是master_repl_offset与slave_repl_offset差值持续扩大、sync_full_ok频发，根本原因是fork子进程阻塞主线程，尤其内存大时fork耗时长导致repl-backlog溢出。
-
根本原因是RedisGEO基于zset实现，每个成员存原始坐标和geohash整数两份数据，且5.0前逐个解析导致跳表与哈希表频繁双更新，叠加浮点转geohash计算开销。
-
Redis集群不自动随机化过期时间，需业务层实现；限流须在应用层或网关层统一控制；热点key需加扰动后缀分散分片；三者叠加（集群+随机过期+限流）且随机范围≥±5%才有效防雪崩。
-
repl-backlog-ttl是Redis主节点在无从节点连接时自动释放复制积压缓冲区的时间阈值，默认3600秒；超时后清空backlog，导致重连从节点无法部分同步而触发开销巨大的全量同步。
-
没有被废弃。LRU在Redis4.0后仍为默认策略之一，6.x、7.x持续优化；LFU是新增而非替代选项；LRU候选池采样逻辑微调但未重构，maxmemory-samples默认值从5升至10再优化分布；lru字段仍为24位，精度受限于194天周期与毫秒级取模，扩展会显著增加内存开销与降低缓存效率。
-
不会阻塞。RDB持久化由fork()子进程执行，主线程继续处理请求；依赖Linux内核写时复制（COW）机制，fork后父子进程共享物理内存页，仅在修改时才复制对应页，保证子进程读取fork时刻快照，但高写入会加剧COW开销。
-
应使用LettuceConnectionFactory替代JedisConnectionFactory，因其原生支持Netty和响应式API；必须配合ReactiveRedisTemplate，并正确配置StringRedisSerializer等序列化器，避免阻塞调用与序列化不匹配问题。
-
Redis4.0起，24位lru字段在LFU模式下拆为高16位ldt（分钟级时间戳）和低8位logc（对数计数器），ldt=(time_t/60)&0xFFFF，logc初始为5并用概率递增算法更新。
-
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。
-
volatile-lru是仅对设置了TTL的key生效的近似LRU淘汰策略，不淘汰无过期时间的key；必须显式配置maxmemory-policy且配合EXPIRE或SETEX使用，否则无效。
-
volatile-lru适合电商购物车场景，但需为每个购物车key显式设置TTL并定期刷新；它仅淘汰带过期时间的key，采样随机且保守，不适用于依赖访问频次的场景。
-
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。
