-
Redis集群不自动随机化过期时间，需业务层实现；限流须在应用层或网关层统一控制；热点key需加扰动后缀分散分片；三者叠加（集群+随机过期+限流）且随机范围≥±5%才有效防雪崩。
-
RedisCluster默认不支持传统Pub/Sub跨节点广播，因频道按slot分片且gossip协议不传播订阅状态，SUBSCRIBE仅在本地节点生效；根本原因在于集群设计只负责数据分片，不实现消息路由。
-
不能。Redis6–7.0的ACL不支持Key前缀通配符（如~tenant:a:），仅支持字面Key名或~；7.0起虽有实验性前缀匹配，但生产未验证且不支持嵌套通配。
-
RedisPub/Sub不支持优先级，仅为瞬时广播；真正优先级队列需用List+BRPOP多键轮询，按queue:high→queue:medium→queue:low顺序原子消费，Pub/Sub仅作轻量通知触发器。
-
setIfAbsent不够安全，因其无法原子性设置过期时间，易导致锁永久不释放；Redis推荐用SETkeyvalueNXEXseconds一步完成，但SpringDataRedis老版本setIfAbsent不支持EX参数。
-
MySQL的查询缓存已废弃，是否还值得使用取决于版本和业务场景。1.查询缓存可缓存SELECT语句及其结果，提升读多写少场景的性能；2.但一旦表有写入操作，相关缓存会被清空，高并发写入时易引发性能问题；3.MySQL5.7.20开始标记为废弃，8.0彻底移除，建议使用Redis等外部缓存替代；4.启用时需配置query_cache_type和query_cache_size参数，并合理控制内存大小；5.可通过Qcache_hits、Com_select、Qcache_inserts等状态变量判断缓存命中情
-
根本原因是sentineldown-after-milliseconds阈值过短，而主库执行耗时Lua脚本导致PING响应超时，哨兵误判为主观下线；典型表现为INFOreplication正常但日志频繁出现+sdown又快速恢复。
-
DEL命令清空List最快，时间复杂度O(1)，原子且单次往返；LTRIM仅在小List中可用，O(N)且保留key；禁用LPOP循环，避免阻塞与残留；清空前需TYPE校验类型。
-
LATENCYDOCTOR无法诊断atop导致的毛刺，因其只监控Redis内部延迟（如事件循环、命令执行、AOF写入），而atop-R读取/proc/pid/smaps触发的内核页表锁争用发生在内核态，Redis用户态线程无法感知。
-
Redis原生String类型无法解析JSON字段，必须用RedisJSON模块实现路径查询、原子更新等能力；启用需加载模块，使用JSON.SET/JSON.GET命令，性能提升体现在频繁子字段操作场景。
-
GEORADIUS返回空结果最常见原因是经纬度顺序写反，必须经度在前、纬度在后；而高德/百度等地图API默认是纬度在前、经度在后，导致坐标存入错误位置。
-
Redis的WATCH+Lua无法实现可靠乐观锁，因WATCH不监控Lua脚本执行，脚本内读-改-写仍存在竞态；真正可靠的是将“读-校验-写”全部封装进单个原子Lua脚本中完成。
