-
RedisStream不受maxmemory-policy淘汰机制影响，仅XADD的MAXLEN/MINID参数可在写入时截断数据；MAXLEN加~为近似截断，不加则严格控制条数，且只从最老端删除；消费者组未XACK会导致PEL积压，MAXLEN无法清理。
-
直接用SETNX易误删锁，因加锁与设过期非原子操作，且释放锁未校验线程标识；正确做法是SET+NX+EX原子加锁并用Lua脚本校验值后删除。
-
哨兵判定主节点“客观下线”失败的常见现象是客户端连接断开、写请求超时，但sentinelinfo显示master-status:ok或sentinels数量不足，本质是哨兵未达成quorum票数共识；原因包括quorum设置过大、哨兵间26379端口不通、monitor配置不一致等。
-
ShedLock通过Redis的SETkeyvalueEXsecondsNX原子命令实现加锁，键为shedlock:{任务名}，值为节点标识，TTL由lockAtMostFor控制；重复执行主因是Redis配置不一致、集群未适配、绕过AOP或TTL过短。
-
setIfAbsent不够安全，因其无法原子性设置过期时间，易导致锁永久不释放；Redis推荐用SETkeyvalueNXEXseconds一步完成，但SpringDataRedis老版本setIfAbsent不支持EX参数。
-
全量复制触发时，Redis主节点必须生成RDB文件，因为从节点初次连接或断连太久后无法仅靠增量命令追上主节点，主节点需将当前完整数据集打包成RDB文件传给从节点以保证状态一致。
-
缓存雪崩主因是大量key过期时间高度趋同，需通过扫描TTL、监控expired_keys曲线及检查写入逻辑验证；应采用SETEX或SET...EX原子命令，在基础过期时间上叠加5%–20%随机偏移，并确保所有写入路径（含定时任务、MQ、后台）均覆盖随机化。
-
彻底禁用RDB自动触发需注释或设为save""，重启或CONFIGREWRITE后CONFIGGETsave返回["save",""]，且rdb_changes_since_last_save持续增长即生效。
-
双重检查是为防缓存击穿：第一次检查过滤命中请求，第二次检查在锁内确认避免重复查库；必须配合空值缓存防穿透、Lua脚本删锁保原子性。
-
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等状态变量判断缓存命中情
-
彻底禁用RDB自动触发需注释或设为save""，重启或CONFIGREWRITE后CONFIGGETsave返回["save",""]，且rdb_changes_since_last_save持续增长即生效。
-
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。
-
Redis集群中requirepass无效，因其仅作用于客户端端口（如6379），不约束集群总线端口（如16379）；节点间通信明文进行，需依赖网络隔离、ACL及正确配置cluster-announce-ip等措施保障安全。
-
根本原因是sentineldown-after-milliseconds阈值过短，而主库执行耗时Lua脚本导致PING响应超时，哨兵误判为主观下线；典型表现为INFOreplication正常但日志频繁出现+sdown又快速恢复。
-
DEL命令清空List最快，时间复杂度O(1)，原子且单次往返；LTRIM仅在小List中可用，O(N)且保留key；禁用LPOP循环，避免阻塞与残留；清空前需TYPE校验类型。
