-
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略：空值需设短过期并避免null值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。
-
RedisPub/Sub不适合生产实时报警系统，因其消息零持久化、无消费确认与重试机制，订阅者断线或处理失败即导致报警永久丢失。
-
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。
-
RedisLua脚本需用原子“读-判-写”实现状态变迁，推荐HASH结构存储多字段（如status、updated_at、version），通过HGETALL/HSET原子操作，结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转，返回结构化结果便于业务判断。
-
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协同识别频繁重连。
-
Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli--latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。
-
RedisHash最适合存购物车，因其天然支持按商品ID（field）原子增减、查询、删除；HINCRBY可安全±数量并自动初始化为0，但需应用层校验负数；key为cart:{user_id}，value仅存整数数量，过期用EXPIRE设置。
-
直接用DEL释放锁会误删其他客户端的锁，因判断持有锁与删除非原子操作；Lua脚本通过原子执行“GET校验+DEL”解决，需传入key和client_id，返回1成功、0失败。
-
缓存雪崩是大量key集中过期或Redis实例不可用导致请求直击数据库，引发数据库过载崩溃；需通过TTL随机偏移错峰过期、熔断降级、本地缓存兜底及禁用危险命令等手段防御。
-
应使用HSET分字段存储用户资料而非SET存JSON，因其支持原子性单字段操作、避免并发覆盖、节省带宽；字段名须全小写下划线；慎用HGETALL防性能陷阱；Hash无内置TTL，需显式EXPIRE。
-
Redis原生SINTER不支持带权重或条件过滤的交集计算，因其仅做纯元素匹配；需用Lua脚本在服务端原子执行复杂逻辑，但须防范阻塞、性能与维护风险。
-
Redis数据丢失后首先确认是否开启持久化，90%情况实为未启用；需用redis-cliconfigget验证运行时AOF/RDB状态，检查appendfsync模式及AOF文件完整性。
-
redis-cli--hotkeys是基于LFU采样的轻量热Key发现工具，需启用allkeys-lfu/volatile-lfu策略，返回最多32个相对高频key，frequency为归一化值，非实时精确计数，须结合objectfreq、monitor等交叉验证。
