-
@Cacheable默认不设过期时间，若统一配置TTL则所有key同步过期易引发雪崩；需通过RedisTemplate手动写入并添加随机偏移（如10分钟±60秒）来缓解。
-
Redis集群不自动随机化过期时间，需业务层实现；限流须在应用层或网关层统一控制；热点key需加扰动后缀分散分片；三者叠加（集群+随机过期+限流）且随机范围≥±5%才有效防雪崩。
-
Redis4.0起，24位lru字段在LFU模式下拆为高16位ldt（分钟级时间戳）和低8位logc（对数计数器），ldt=(time_t/60)&0xFFFF，logc初始为5并用概率递增算法更新。
-
volatile-lru是仅对设置了TTL的key生效的近似LRU淘汰策略，不淘汰无过期时间的key；必须显式配置maxmemory-policy且配合EXPIRE或SETEX使用，否则无效。
-
CLUSTERKEYSLOT仅执行CRC16(key)mod16384计算，返回0–16383的槽号，不查询集群拓扑或节点信息；定位具体实例需配合CLUSTERSLOTS或CLUSTERNODES查找槽所属节点。
-
直接用SETNX易误删锁，因加锁与设过期非原子操作，且释放锁未校验线程标识；正确做法是SET+NX+EX原子加锁并用Lua脚本校验值后删除。
-
哨兵判定主节点“客观下线”失败的常见现象是客户端连接断开、写请求超时，但sentinelinfo显示master-status:ok或sentinels数量不足，本质是哨兵未达成quorum票数共识；原因包括quorum设置过大、哨兵间26379端口不通、monitor配置不一致等。
-
ShedLock通过Redis的SETkeyvalueEXsecondsNX原子命令实现加锁，键为shedlock:{任务名}，值为节点标识，TTL由lockAtMostFor控制；重复执行主因是Redis配置不一致、集群未适配、绕过AOP或TTL过短。
-
全量复制触发时，Redis主节点必须生成RDB文件，因为从节点初次连接或断连太久后无法仅靠增量命令追上主节点，主节点需将当前完整数据集打包成RDB文件传给从节点以保证状态一致。
-
彻底禁用RDB自动触发需注释或设为save""，重启或CONFIGREWRITE后CONFIGGETsave返回["save",""]，且rdb_changes_since_last_save持续增长即生效。
-
双重检查是为防缓存击穿：第一次检查过滤命中请求，第二次检查在锁内确认避免重复查库；必须配合空值缓存防穿透、Lua脚本删锁保原子性。
-
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。
-
Redis集群参数中，cluster-enabled、cluster-config-file、cluster-node-timeout等不支持热调整，CONFIGSET看似成功实则被忽略；真正可热调的仅timeout、tcp-keepalive、maxmemory-policy等少数非核心参数。
-
RedisPub/Sub监控需聚焦连接行为与资源消耗：用PUBSUBNUMSUB查实时订阅数，instantaneous_output_kbps和client_longest_output_list组合判断积压，connected_clients与connections_received_per_sec协同识别频繁重连。
-
是的。shutdown默认执行同步RDB保存，前提是redis.conf中存在未注释的有效save规则（如save6010000），且磁盘空间充足、无阻塞命令；它会先落盘再断连最后退出。
