-
预热不充分指预热数据未覆盖真实热点、未执行完或未及时更新，导致上线后2–5分钟内缓存击穿；须用线上采样等动态数据源、分批超时控制、命中率校验及事件驱动机制。
-
volatile-ttl策略仅在内存达限且有写入时触发，随机采样已设TTL的key并淘汰其中剩余过期时间最短者，并非主动或精准清理“马上过期”的key。
-
RedisTemplate操作Hash返回null的主因是序列化器不一致：key、hashKey、value三者序列化方式必须匹配，尤其hashKey须用StringRedisSerializer，value推荐Jackson序列化，否则反序列化失败或读不到数据。
-
intset是Redis对全整数小集合的内存优化编码，将整数紧凑存储于连续内存，无指针和字符串头开销，比hashtable节省3–5倍内存；前提为元素均为合法64位有符号整数且数量不超set-max-intset-entries（默认512）。
-
直接看INFOclients的qbuf、qbuf-free、obl、oll、omem字段可判断单个客户端流量压力：qbuf高说明命令积压，omem>2MB或qbuf>1MB且持续高位表明高频写入或返回大数据；CLIENTLIST才能定位具体异常客户端，需重点关注qbuf与omem同时偏高、idle小但qbuf大的连接。
-
Redis6.2+需用--cluster参数运行redis-benchmark，否则MOVED/ASK重定向导致QPS归零；低版本需手动固定槽位或升级。
-
allkeys-random并非真正无差别：它只在内存达限且写入触发时，从永不过期的主字典key中伪随机删除，不考虑访问频次、大小或热度，易误删热图；应改用allkeys-lru或ZSET+定时清理。
-
XREADGROUP能自动负载均衡，因Redis服务端按轮询策略将新消息分发给组内不同消费者，确保同条消息仅投递一次；未ACK消息超时后可被其他消费者XCLAIM接管，实现故障转移。
-
必须分片，因单keyGEOADD底层ZSET会导致查询O(logN+M)延迟、RDB/AOFfork超时、无法水平扩展；应按Geohash前4-5位分key，查时用邻区算法并发查最多9个key并合并去重排序。
-
直接调大save触发阈值是最有效、最安全的手段，通过修改redis.conf中save配置项（如将save6010000改为save30050000），可降低RDB快照频率，缓解磁盘IO压力，但需结合数据丢失容忍度与写入节奏合理设置。
-
cluster-node-timeout合理值需根据网络P95延迟×2～3倍设定，局域网常见5000～8000ms，跨机房12000～15000ms，容器环境不低于8000ms；须全节点一致，CONFIGSET仅内存生效，持久化需改配置文件并重启；扩缩容前应临时调大，且tcp-keepalive需配合设置。
-
RedisPub/Sub不支持自动消息压缩，因PUBLISH内容直写输出缓冲区，绕过LZF等内存压缩逻辑；需客户端自行压缩/解压，并统一算法；高频短消息推荐LZ4/Snappy；长期应改用Stream替代。
-
Pub/Sub是无存储的实时广播机制，消息断连即丢，适合允许丢失的在线通知；Stream是带ACK的持久化消息队列，支持回溯、消费者组和精确控制，但需手动管理XACK与MAXLEN。
-
根本原因是repl-backlog-size过小或网络闪断超时，导致从节点重连时偏移量超出缓冲区范围而无法增量同步，被迫触发全量同步。
-
Redis6.0多线程不加速命令执行，仅I/O多线程+pipeline组合可提升导入效率；需客户端用pipeline打包发送，且主线程不饱和时才有效。
