-
应使用LettuceConnectionFactory替代JedisConnectionFactory，因其原生支持Netty和响应式API；必须配合ReactiveRedisTemplate，并正确配置StringRedisSerializer等序列化器，避免阻塞调用与序列化不匹配问题。
-
Redis从库默认只读，slave-read-onlyyes是防意外写入的保险栓；设为no后从库可写但导致主从数据不一致，因写命令不回传主库且故障转移会扩散脏数据。
-
Redis4.0起，24位lru字段在LFU模式下拆为高16位ldt（分钟级时间戳）和低8位logc（对数计数器），ldt=(time_t/60)&0xFFFF，logc初始为5并用概率递增算法更新。
-
集群模式下slave-read-onlyyes无效，因集群协议绕过主从配置；必须用readonly命令开启连接级只读，使从节点响应本主槽读请求。
-
应先检查是否连接泄露，再调整maxclients：通过redis-cliclientlist确认连接是否持续增长，修复Jedis未close问题；若确需扩容，须同步调高系统ulimit-n并重启Redis。
-
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。
-
RedisCluster默认不支持传统Pub/Sub跨节点广播，因频道按slot分片且gossip协议不传播订阅状态，SUBSCRIBE仅在本地节点生效；根本原因在于集群设计只负责数据分片，不实现消息路由。
-
Pub/Sub频道命名必须带租户前缀，采用三段式结构{租户标识}:{业务域}:{实体ID}，禁用裸频道和通配符泛订阅；ACL需按前缀精确控制，显式授权+subscribe/+publish；TLS与消息体加密必须同时启用；Pub/Sub不可替代可靠队列，应改用Stream或List。
-
volatile-lru是仅对设置了TTL的key生效的近似LRU淘汰策略，不淘汰无过期时间的key；必须显式配置maxmemory-policy且配合EXPIRE或SETEX使用，否则无效。
-
是，HLL适合统计日活UV，但需接受约0.81%误差且不支持成员查询与精确交集；按日期分key（如uv:20240520）、设过期、统一用户标识方可稳健使用。
-
不能。Redis6–7.0的ACL不支持Key前缀通配符（如~tenant:a:），仅支持字面Key名或~；7.0起虽有实验性前缀匹配，但生产未验证且不支持嵌套通配。
-
volatile-lru适合电商购物车场景，但需为每个购物车key显式设置TTL并定期刷新；它仅淘汰带过期时间的key，采样随机且保守，不适用于依赖访问频次的场景。
-
RedisPub/Sub不支持优先级，仅为瞬时广播；真正优先级队列需用List+BRPOP多键轮询，按queue:high→queue:medium→queue:low顺序原子消费，Pub/Sub仅作轻量通知触发器。
-
volatile-ttl策略仅在内存达限且有写入时触发，随机采样已设TTL的key并淘汰其中剩余过期时间最短者，并非主动或精准清理“马上过期”的key。
-
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。
