-
Redis内存未立即下降是因为采用惰性+定期双机制清理过期key，定期清理受hz参数控制；hz越大扫描越频繁但CPU开销越高，默认10，调至100可加速清理，超100收益递减且可能引发高CPU。
-
会，Redis主从同步常打爆网卡，尤其跨机房、大key迁移或全量复制时；因Redis无带宽限速参数，需用tc对主节点6379端口出向流量限速，并调大repl-timeout防超时断连。
-
RedisAOF是将写命令追加到文件以实现持久化，但并非所有场景都适用：appendfsync配置影响安全性与性能，everysec是线上折中选择，always性能差，no不可靠；AOF重写可能耗资源，切换时需检查文件完整性、路径及时间戳。
-
OBJECTFREQ返回key的LFU近似频次（0–255），多次GET后应上升；频次非线性增长、有衰减、依赖serverCron更新，需确认Redis≥4.0、maxmemory-policy正确配置且内存压力存在。
-
单靠Redis命令无法保证双写缓存原子性，因SET和DEL是两个独立命令，中间可能被其他客户端插入操作，导致缓存与DB不一致；Lua脚本在服务端单线程原子执行，可规避竞态。
-
Redis性能瓶颈主要出现在硬件、配置和应用层面。1.硬件层面：内存不足和CPU性能低下可能导致性能问题。2.配置层面：不当的持久化和网络配置会影响性能。3.应用层面：大Key、大Value和不合理缓存策略是常见问题。通过监控和优化，可以有效提升Redis性能。
-
布隆过滤器必须前置到请求入口，如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端口双向通信，最后才调整哨兵参数。
-
延迟双删删的是第一次更新前删缓存、第二次更新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等少数非核心参数。
