-
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。
-
RedisPub/Sub不适用于金融交易场景，因其纯内存、无持久化、无确认机制，导致消息必然丢失；集群下无全局顺序且不支持事务，应改用Streams或Kafka。
-
哨兵选主失败或频繁切换的根本原因是时钟偏差过大或网络单向隔离；需先用ntpstat和chronyctracking检查时钟同步，再用tcpdump验证26379端口双向通信，最后才调整哨兵参数。
-
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等外部工具完成。
-
能，从库可记录慢查询日志但需在redis.conf中显式配置slowlog-log-slower-than和slowlog-max-len，主库配置不自动同步，且慢日志为实例级本地行为。
-
能，但需满足版本一致、关闭AOF、RDB文件路径和名称匹配、权限正确等硬性条件，否则启动报错或数据不一致。
-
不能直接用@Primary切换Redis数据源，因其仅指定启动时默认Bean，无法运行时动态路由；需用ThreadLocal持有当前线程的ConnectionFactory，并配合AOP在方法级按需绑定与清理。
-
是的。shutdown默认执行同步RDB保存，前提是redis.conf中存在未注释的有效save规则（如save6010000），且磁盘空间充足、无阻塞命令；它会先落盘再断连最后退出。
-
appendfsynceverysec仍可能阻塞主线程，是因为当后台fsync未完成而缓冲区有新数据时，主线程会同步等待；根本原因是磁盘慢导致单次fsync超1秒，触发安全兜底机制。
