-
Redis内存飙升多因bigkey，应优先在从节点用redis-cli--bigkeys扫描，避免主节点阻塞；它仅返回每类最大key且不反映真实内存，需结合MEMORYUSAGE和访问频次进一步分析。
-
repl-backlog-ttl是Redis主节点在无从节点连接时自动释放复制积压缓冲区的时间阈值，默认3600秒；超时后清空backlog，导致重连从节点无法部分同步而触发开销巨大的全量同步。
-
Redis集群不处理小文件，RDB压缩是单节点操作；每个主节点独立生成并压缩dump.rdb，仅支持内置LZF压缩，高率压缩需备份后用zstd等外部工具完成。
-
Redis集群中requirepass无效，因其仅作用于客户端端口（如6379），不约束集群总线端口（如16379）；节点间通信明文进行，需依赖网络隔离、ACL及正确配置cluster-announce-ip等措施保障安全。
-
@Cacheable默认不设过期时间，若统一配置TTL则所有key同步过期易引发雪崩；需通过RedisTemplate手动写入并添加随机偏移（如10分钟±60秒）来缓解。
-
RedisStream不受maxmemory-policy淘汰机制影响，仅XADD的MAXLEN/MINID参数可在写入时截断数据；MAXLEN加~为近似截断，不加则严格控制条数，且只从最老端删除；消费者组未XACK会导致PEL积压，MAXLEN无法清理。
-
不能直接用@Primary切换Redis数据源，因其仅指定启动时默认Bean，无法运行时动态路由；需用ThreadLocal持有当前线程的ConnectionFactory，并配合AOP在方法级按需绑定与清理。
-
必须配合日期动态生成key，因Bitmap无时间维度，共用key会丢失日期信息且导致单key膨胀、RDB/AOF暴增、主从延迟；用户ID须映射为非负整数offset，避免直接强转；BITCOUNT偏高多因key未清理或offset错位；5000万DAU下Bitmap体积约6.25MB，但需防ID稀疏浪费内存。
-
直接引入spring-session-data-redis即可，它自动适配SpringBoot2.7+的Lettuce；避免手动引入jedis、错误配置redis属性、使用默认JDK序列化，需改用GenericJackson2JsonRedisSerializer，并确保Redis高可用与Cookie正确隔离。
-
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。
-
从节点默认不执行任何过期逻辑，仅重放主节点发来的DEL等命令；必须设maxmemory-policy为noeviction（或7.0+启用replica-ignore-maxmemoryyes）防止主动淘汰破坏一致性。
-
Redis发布订阅不保存历史消息，因此SUBSCRIBE收不到已发布的消息；审计必须由发布端主动同步写入持久化存储，不能依赖Pub/Sub自身机制。
-
根本原因是复制积压缓冲区（repl-backlog）持续增长：失联从节点未被及时清理时，主节点仍向共享的环形缓冲区追加命令，导致内存只增不减；repl-diskless-sync仅影响全量同步传输方式，不控制增量缓存，真正关键的是repl-timeout与client-output-buffer-limitslave协同配置以主动断连并释放内存。
-
appendfsynceverysec仍可能阻塞主线程，是因为当后台fsync未完成而缓冲区有新数据时，主线程会同步等待；根本原因是磁盘慢导致单次fsync超1秒，触发安全兜底机制。
