-
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。
-
Redis7的Multi-PartAOF是将写操作分散到多个小文件（如.base.rdb和.incr.aof）的机制，本质区别在于重写不再依赖全量内存快照和fork子进程，而是通过异步追加与增量合并实现，内存占用稳定在几十MB。
-
AOF重写后文件变大是因为重写时仍会写入带过期时间但尚未过期的key，尤其高频短TTL的SET/EXPIREAT等指令堆积且无法压缩，导致AOF体积膨胀。
-
网卡PPS打满是吞吐量上不去的常见原因，尤其在小key/value场景下，单请求虽仅60–100字节却生成独立TCP包，易使网卡达到硬件上限。
-
bgsave不阻塞Redis主线程，因其fork后由子进程独立完成RDB生成，主线程立即恢复服务；卡顿仅发生在fork阶段，大内存实例页表复制开销显著。
-
Redis集群写入失败需先确认是否真不可写：常见原因是客户端连只读节点或未处理ASK/MOVED重定向；检查CLUSTERNODES中fail?（疑似下线）或fail（客观下线）状态；CLUSTERFAILOVER仅在从节点、主节点在线、偏移量合规且非CLUSTERDOWN时生效；主节点宕机且无自动转移时，才需在健康从节点执行CLUSTERFAILOVERFORCE，并对旧主执行CLUSTERRESETHARD。
-
SPOP是真正随机的，底层用Fisher-Yates变种算法对当前存在元素随机抽取；但因哈希表桶分布和短时随机种子偏差，可能感觉“不均匀”，非bug。
-
RedisStream比PUB/SUB更适合做持久化队列，因其支持消息持久化、消费者组、ACK机制、唯一消息ID和按位置回溯；PUB/SUB纯内存广播，无存储、无堆积能力。
-
SINTER是Redis中计算共同好友唯一靠谱、原子、高效的方式，它基于内存集合运算，自动选取最小集合优化性能，毫秒级返回结果，避免网络往返与客户端计算开销。
-
RDB快照非实时落盘，依赖bgsave子进程异步生成，期间新写入数据不包含在本次快照中；AOF重写通过双缓冲保障新命令不丢失；混合持久化仅存储格式混合，写入仍按appendfsync策略执行。
-
RedisCommandTimeoutException本质是命令执行完成但客户端未及时收到响应，与连接池大小无关；应优先调整command-timeout、keepalive及tcpUserTimeout等网络层参数。
-
Redis键空间事件默认关闭，需配置notify-keyspace-events为KEA等组合才生效；事件频道名格式严格、无历史回放、过期事件延迟不可靠、断连事件丢失且无自动续订。
-
Redis主从读写分离需客户端显式控制，服务端仅同步数据；可通过API探测节点角色、配置双连接池或使用Lettuce的ReadFrom.SLAVE_PREFERRED实现路由，同时须校验从节点只读模式、健康状态与复制延迟。
-
Redis集群原生不支持灰度发布，需通过Proxy（如Predixy）或客户端SDK实现key前缀路由，注意代理高可用、跨集群事务拦截、连接池隔离及日志打标。
-
AOF重写期间used_memory_rss突然翻倍，根本原因是Redis启用双缓冲机制并触发COW大量页复制。主进程同时维护新旧AOF缓冲区，大Key修改或哈希扩容导致RSS飙升1.5–2倍，OOMkiller可能介入。
