-
volatile-lru适合电商购物车场景，但需为每个购物车key显式设置TTL并定期刷新；它仅淘汰带过期时间的key，采样随机且保守，不适用于依赖访问频次的场景。
-
根本原因是RedisGEO基于zset实现，每个成员存原始坐标和geohash整数两份数据，且5.0前逐个解析导致跳表与哈希表频繁双更新，叠加浮点转geohash计算开销。
-
GEOPOS查不到数据主因是GEOADD未成功：参数顺序错误（须经度在前）、成员名不一致、或pipeline/事务中未等命令执行完；返回值为二维数组，含字符串型经纬度及null，需显式转换且验证存在性。
-
Redis不内置BloomFilter，需借助Redisson等第三方实现；EXISTS和空值缓存无法有效防穿透，因前者不拦截非法ID、后者易致缓存污染；布隆过滤器以极小空间开销提供高效存在性否定判断。
-
JedisPool不自动处理主从切换或断连重连，需应用层干预；卡住主因是连接池耗尽或失效连接未剔除，而非未重连。
-
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。
-
主从同步断开时repl-backlog溢出会导致全量同步反复触发；需根据写入速率与最大重连时间估算合理大小，动态调整后须同步更新配置文件。
-
应使用LettuceConnectionFactory替代JedisConnectionFactory，因其原生支持Netty和响应式API；必须配合ReactiveRedisTemplate，并正确配置StringRedisSerializer等序列化器，避免阻塞调用与序列化不匹配问题。
-
RedisPub/Sub不能替代RabbitMQ，因其不保证消息可达、无持久化订阅、无消费确认机制，消息丢失理直气壮；它纯内存广播，断连、重启后消息全丢，无积压、无offset、无重试，仅适用于允许丢失的实时轻量场景。
-
sentinelmonitor三要素（master-name、IP、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），ACL还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
-
RedisPub/Sub不直接产生内存碎片，但未清理的订阅连接、消息积压或缓冲区配置不当会推高used_memory_rss，导致mem_fragmentation_ratio偏高，形成“假性碎片”；真实碎片源于键值对频繁增删改，而Pub/Sub缓冲区不受active-defrag影响。
-
Redis大Value导致网卡打满的典型现象是业务延迟飙升、连接超时且网卡出向流量持续90%+，而CPU和内存正常；根本原因是GET/HGETALL返回几十MB未压缩value，在客户端与Redis间反复传输；Redis服务端不支持自动压缩，必须由客户端在序列化后、写入前用LZ4（推荐）或GZIP压缩，并在key中标记压缩方式，读取时依标识解压，否则易因误解bytes为str或跳过校验导致乱码或异常。
-
Redis原生SINTER不支持带权重或条件过滤的交集计算，因其仅做纯元素匹配；需用Lua脚本在服务端原子执行复杂逻辑，但须防范阻塞、性能与维护风险。
-
能，从库可记录慢查询日志但需在redis.conf中显式配置slowlog-log-slower-than和slowlog-max-len，主库配置不自动同步，且慢日志为实例级本地行为。
-
哨兵选主失败或频繁切换的根本原因是时钟偏差过大或网络单向隔离；需先用ntpstat和chronyctracking检查时钟同步，再用tcpdump验证26379端口双向通信，最后才调整哨兵参数。
