-
Redis6.0+才正式支持volatile-lfu和allkeys-lfu，低版本会静默降级为LRU；需通过CONFIGGET/SET确认并热生效策略，商品Key须按粒度命名（如prod:sku:10086）并用INCR+EXPIRE维护热度，OBJECTFREQ返回0–255近似值仅适用于相对排序，不反映真实访问次数。
-
redis-cli--hotkeys是基于LFU采样的轻量热Key发现工具，需启用allkeys-lfu/volatile-lfu策略，返回最多32个相对高频key，frequency为归一化值，非实时精确计数，须结合objectfreq、monitor等交叉验证。
-
EVAL需原子性保证竞态安全，因Redis将Lua脚本作为不可分割的单次操作执行，避免“先查后改”在高并发下的数据丢失；其原子性非源于Lua线程安全，而是Redis调度机制保障。
-
sentinelmonitor三要素（master-name、IP、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），ACL还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
-
大key在Redis主从同步中会触发复制断连，表现为从库state由online突变为offline、日志反复出现Connectionwithmasterlost和Resyncingfrommaster，根源是RDB/AOF传输超时或内存溢出。
-
哨兵故障转移实际耗时为2–30秒，并非毫秒级；“毫秒级”仅指心跳检测与投票过程。真实恢复时间受down-after-milliseconds配置（建议5000–10000ms）、哨兵多数派机制及客户端行为影响，需配合写前校验或代理层使用。
-
Redis大Value导致网卡打满的典型现象是业务延迟飙升、连接超时且网卡出向流量持续90%+，而CPU和内存正常；根本原因是GET/HGETALL返回几十MB未压缩value，在客户端与Redis间反复传输；Redis服务端不支持自动压缩，必须由客户端在序列化后、写入前用LZ4（推荐）或GZIP压缩，并在key中标记压缩方式，读取时依标识解压，否则易因误解bytes为str或跳过校验导致乱码或异常。
-
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。
-
Redis单个STRING超10MB必须拆分，建议512KB内切片并用GETRANGE/SETRANGE操作；BigHash应按访问频次和语义拆为小Hash，禁用HGETALL；一致性靠Lua脚本或状态字段+重试保障。
-
Redis7.0的String类型未新增任何操作指令，所有内存优化均源于SDS编码策略的自动演进，如按长度动态选用sdshdr8/sdshdr16及预分配冗余空间，无需用户干预。
-
最小可行路径是为每个用户创建独立Set键（如user:123:tags），用SADD添加标签、SMEMBERS查询，确保标签标准化；避免字符串拼接、KEYS扫描及反向索引维护，高频查询再引入RedisSearch或Elasticsearch。
-
缓存雪崩主因是大量key过期时间高度趋同，需通过扫描TTL、监控expired_keys曲线及检查写入逻辑验证；应采用SETEX或SET...EX原子命令，在基础过期时间上叠加5%–20%随机偏移，并确保所有写入路径（含定时任务、MQ、后台）均覆盖随机化。
-
开启lazyfree-lazy-evictionyes且Redis≥6.0后，淘汰策略触发的内存释放由后台线程异步执行，主线程不再被同步释放大Key卡住。
-
Redis有序集合仅按score排序，不支持多字段或条件排序；需用Lua脚本在服务端原子重排，如score相同时按name字典序，避免客户端排序导致的性能与一致性问题。
-
根本原因是客户端将从节点视为独立服务端并为每个从节点创建独立连接池。开启读写分离后，Jedis/Lettuce会主动发现并连接所有从节点，导致连接数激增、从库负载过高；解决关键是禁用客户端拓扑发现，改用代理层统一入口或手动控制连接复用。
