-
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。
-
应使用Redis的Hash或ZSet维护用户会话映射，新登录时先获取并删除旧会话缓存及黑名单，配合事务或Lua脚本保证并发安全，而非仅依赖EXPIRE。
-
Redis7.0的String类型未新增任何操作指令，所有内存优化均源于SDS编码策略的自动演进，如按长度动态选用sdshdr8/sdshdr16及预分配冗余空间，无需用户干预。
-
RedisPubSub不支持批量publish，因协议层限制且pipeline无法减少网络往返；可行方案是业务层聚合消息为结构化数据（如JSON数组）后单次发送，并合理控制聚合窗口与消息体积。
-
SpringBoot中@Cacheable不支持动态过期时间，因SpringCache抽象层仅支持全局TTL配置；需通过RedisTemplate手动设expire、多CacheManager配置或自定义RedisCacheWriter实现差异化TTL。
-
应通过aof_rewrite_in_progress、aof_pending_rewrite、aof_last_bgrewrite_status三字段组合判断AOF重写是否真正完成：前两者为0且后者为ok才表示成功；仅凭aof_last_rewrite_time_sec或单个字段易误判。
-
Bitmap签到本质是将日期转为从基准日开始的天数差作为offset，用SETBIT操作位；需统一UTC时区、避免手算闰年、单用户单key（如sign:uid:12345）、按月分key更实用，查连续签到须结合日期范围校验offset。
-
单靠DECR会超卖，因其校验库存是否>0与扣减是两步非原子操作，高并发下多个客户端可能同时读到库存=1后均执行DECR导致负数；必须用Lua脚本将判断与扣减封装为单次原子执行。
-
dump.rdb文件越积越多是因为Redis默认不自动清理旧快照，每次bgsave生成新文件但保留旧文件，需依赖外部脚本按时间戳安全清理。
