-
volatile-ttl策略仅在内存达限且有写入时触发，随机采样已设TTL的key并淘汰其中剩余过期时间最短者，并非主动或精准清理“马上过期”的key。
-
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。
-
RedisPub/Sub不直接产生内存碎片，但未清理的订阅连接、消息积压或缓冲区配置不当会推高used_memory_rss，导致mem_fragmentation_ratio偏高，形成“假性碎片”；真实碎片源于键值对频繁增删改，而Pub/Sub缓冲区不受active-defrag影响。
-
CLUSTERKEYSLOT仅执行CRC16(key)mod16384计算，返回0–16383的槽号，不查询集群拓扑或节点信息；定位具体实例需配合CLUSTERSLOTS或CLUSTERNODES查找槽所属节点。
-
Redis6.2+需用--cluster参数运行redis-benchmark，否则MOVED/ASK重定向导致QPS归零；低版本需手动固定槽位或升级。
-
allkeys-random并非真正无差别：它只在内存达限且写入触发时，从永不过期的主字典key中伪随机删除，不考虑访问频次、大小或热度，易误删热图；应改用allkeys-lru或ZSET+定时清理。
-
必须分片，因单keyGEOADD底层ZSET会导致查询O(logN+M)延迟、RDB/AOFfork超时、无法水平扩展；应按Geohash前4-5位分key，查时用邻区算法并发查最多9个key并合并去重排序。
-
直接调大save触发阈值是最有效、最安全的手段，通过修改redis.conf中save配置项（如将save6010000改为save30050000），可降低RDB快照频率，缓解磁盘IO压力，但需结合数据丢失容忍度与写入节奏合理设置。
-
RedisStream不受maxmemory-policy淘汰机制影响，仅XADD的MAXLEN/MINID参数可在写入时截断数据；MAXLEN加~为近似截断，不加则严格控制条数，且只从最老端删除；消费者组未XACK会导致PEL积压，MAXLEN无法清理。
-
根本原因是repl-backlog-size过小或网络闪断超时，导致从节点重连时偏移量超出缓冲区范围而无法增量同步，被迫触发全量同步。
-
不能直接用RedisPub/Sub做缓存一致性保障，因其不保证消息可达，订阅者离线时消息丢失，无重试、ACK或持久化机制；必须结合RedisStream落地事件+数据库状态校验实现最终一致。
-
ZUNIONSTORE合并多个ZSet时相同member的score默认相加；海量数据下会严重阻塞Redis主线程；需注意目标key编码、memberID统一及分批合并等实践要点。
-
AOF文件无法直接看出某条key被谁改过，因其仅记录命令文本，不包含时间戳、客户端ID或用户标识；需通过业务层打标或Proxy日志实现审计溯源。
-
从节点默认不执行任何过期逻辑，仅重放主节点发来的DEL等命令；必须设maxmemory-policy为noeviction（或7.0+启用replica-ignore-maxmemoryyes）防止主动淘汰破坏一致性。
-
RedisStreams用XADD存操作日志最直接，天然按毫秒级时间戳排序，支持XREAD/XRANGE按时间范围查询，需设MAXLEN防爆涨，多服务通过consumergroup共享且互不干扰，持久化依赖AOF配置。
