-
sentinelmonitor三要素（master-name、IP、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），ACL还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
-
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集群参数中，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协同识别频繁重连。
-
@Cacheable默认不设过期时间，若统一配置TTL则所有key同步过期易引发雪崩；需通过RedisTemplate手动写入并添加随机偏移（如10分钟±60秒）来缓解。
-
必须配合日期动态生成key，因Bitmap无时间维度，共用key会丢失日期信息且导致单key膨胀、RDB/AOF暴增、主从延迟；用户ID须映射为非负整数offset，避免直接强转；BITCOUNT偏高多因key未清理或offset错位；5000万DAU下Bitmap体积约6.25MB，但需防ID稀疏浪费内存。
-
Redis内存飙升多因bigkey，应优先在从节点用redis-cli--bigkeys扫描，避免主节点阻塞；它仅返回每类最大key且不反映真实内存，需结合MEMORYUSAGE和访问频次进一步分析。
-
Redis集群中requirepass无效，因其仅作用于客户端端口（如6379），不约束集群总线端口（如16379）；节点间通信明文进行，需依赖网络隔离、ACL及正确配置cluster-announce-ip等措施保障安全。
-
Redis集群不处理小文件，RDB压缩是单节点操作；每个主节点独立生成并压缩dump.rdb，仅支持内置LZF压缩，高率压缩需备份后用zstd等外部工具完成。
-
能，但需满足版本一致、关闭AOF、RDB文件路径和名称匹配、权限正确等硬性条件，否则启动报错或数据不一致。
-
不能直接用@Primary切换Redis数据源，因其仅指定启动时默认Bean，无法运行时动态路由；需用ThreadLocal持有当前线程的ConnectionFactory，并配合AOP在方法级按需绑定与清理。
-
是的。shutdown默认执行同步RDB保存，前提是redis.conf中存在未注释的有效save规则（如save6010000），且磁盘空间充足、无阻塞命令；它会先落盘再断连最后退出。
-
appendfsynceverysec仍可能阻塞主线程，是因为当后台fsync未完成而缓冲区有新数据时，主线程会同步等待；根本原因是磁盘慢导致单次fsync超1秒，触发安全兜底机制。
-
JedisPool不自动处理主从切换或断连重连，需应用层干预；卡住主因是连接池耗尽或失效连接未剔除，而非未重连。
