-
RedisLua脚本需用原子“读-判-写”实现状态变迁，推荐HASH结构存储多字段（如status、updated_at、version），通过HGETALL/HSET原子操作，结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转，返回结构化结果便于业务判断。
-
RedisTemplate操作Hash返回null的主因是序列化器不一致：key、hashKey、value三者序列化方式必须匹配，尤其hashKey须用StringRedisSerializer，value推荐Jackson序列化，否则反序列化失败或读不到数据。
-
Redis6.0多线程不加速命令执行，仅I/O多线程+pipeline组合可提升导入效率；需客户端用pipeline打包发送，且主线程不饱和时才有效。
-
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略：空值需设短过期并避免null值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。
-
Redis6+的io-threads应设为2~8，不超过磁盘队列深度的2倍，且必须保持io-threads-do-readsno；它仅加速写入内核页缓存，不加速fsync，设得过多反而加剧IOWAIT和延迟。
-
能，但仅限Redis服务器端EVAL/EVALSHA上下文；需用正确日志级别常量和预拼接字符串，且依赖redis.conf中loglevel和logfile配置生效。
-
INFOkeyspace无法反映淘汰情况，因其仅统计存活key数量，不区分已过期未删除或已被淘汰的key，且不记录evicted_keys等关键淘汰指标。
-
预热不充分指预热数据未覆盖真实热点、未执行完或未及时更新，导致上线后2–5分钟内缓存击穿；须用线上采样等动态数据源、分批超时控制、命中率校验及事件驱动机制。
-
SpringBoot默认不开启Redis读写分离，纯主从模式下即使配置read-from也无效；必须使用哨兵/集群模式或自定义MasterReplica.connect()，并配合LettuceClientConfigurationBuilderCustomizer注入ReadFrom.REPLICA_PREFERRED才能生效。
-
缓存击穿需用Redis原子命令SETkeyvalueEXsecondsNX加key级互斥锁，配合Lua脚本安全解锁；推荐RedissonRLock自动续期，空值缓存需权衡数据一致性与性能。
-
需结合XINFOCONSUMERS与XINFOGROUPS判断Streams实时消费延迟：关注pel-count、pending数、idle值及last-delivered-id与流尾ID的字典序比较，避免误判离线或假死状态。
-
+sdown表示单个哨兵认定主节点失联，+odown才是触发故障转移的共识临界点；两者时间差暴露网络或配置问题，+odown后还需经选举、选从库、提升等步骤才能完成切换。
-
Redis默认单线程设计，仅用一个CPU核，多核需通过部署多个实例分摊压力；Redis7.0的--server-workers仅加速网络I/O，不提升命令执行并发。
-
Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli--latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。
-
Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli--latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。
