-
reshard搬的是Slot而非Key，先重分配16384个Slot，再由集群自动触发Key迁移；需待“Allkeystransferred”提示才完成，且新节点须完成注册、握手、身份确认三步并满足网络与配置要求。
-
必须显式配置client-output-buffer-limit，否则普通客户端无输出缓冲区上限，易致内存耗尽；需为normal、pubsub等类型分别设置hard/soft限制，尤其pubsub缓冲区最易失控。
-
要定位被淘汰的key，需监控evicted_keys增量、expired_keys飙升情况，并结合Redis7.0+的MEMORYUSAGE与OBJECTFREQ抽样分析；allkeys-lru不安全，应优先用volatile-lru/lfu；LFU更耗CPU因频次衰减更新；验证key是否频繁淘汰可用PFADD+PFCOUNT埋点统计。
-
ZREM不能直接删除Geo数据，因为它只删除ZSET中的member名称，而非按经纬度范围删除；必须先用GEORADIUS等命令查询出目标member，再调用ZREM精确删除。
-
Redis主从切换后连接池未刷新导致请求超时或Connectionrefused，因Jedis/Lettuce默认不自动感知拓扑变更；需手动重建连接池或使用Lettuce6.0+内置重连机制。
-
必须配合日期动态生成key，因Bitmap无时间维度，共用key会丢失日期信息且导致单key膨胀、RDB/AOF暴增、主从延迟；用户ID须映射为非负整数offset，避免直接强转；BITCOUNT偏高多因key未清理或offset错位；5000万DAU下Bitmap体积约6.25MB，但需防ID稀疏浪费内存。
-
Redis布隆过滤器不支持动态扩容，BF.RESERVE设定的capacity和error_rate不可修改；扩容需手动迁移数据并切换key，参数选错易致内存激增或OOM。
-
缓存击穿是热点key过期瞬间并发请求涌向DB，需用逻辑过期、随机过期时间、分级预热、互斥锁及行为验证来防控。
-
应优先使用pipeline批量发命令替代单条轮询，避免高RTT开销；对计数类操作用INCR/DECR原子增减；设值带过期统一用SET的EX/PX/NX参数；高频读不变Key应加客户端本地缓存。
-
不能。volatile-ttl仅在内存不足时随机采样少量带过期时间的key淘汰TTL最小者，并非定时批量清理；高QPS下写入快于淘汰易致OOM，需配合随机偏移、调优采样数、限流及兜底策略。
-
RedisCommandTimeoutException本质是命令执行完成但客户端未及时收到响应，与连接池大小无关；应优先调整command-timeout、keepalive及tcpUserTimeout等网络层参数。
-
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。
-
发布订阅模式适合实时性要求极高、可容忍消息丢失、一对多广播型通知场景，如服务状态广播、实时日志分发、WebSocket用户事件广播；Stream适合需持久化、至少一次投递、支持消费者组与重试的场景，如订单异步处理、用户行为埋点、审计日志归档。
-
RedisLua脚本执行失败常因忽略redis.call()返回值，应检查是否为错误表；EVALSHA需确保脚本已重载；redis.log()日志需调高loglevel且查服务端文件；KEYS必须显式声明，禁用KEYS命令。
-
主库卡顿导致从库失联时，应先执行INFOreplication检查connected_slaves、master_repl_offset和repl_backlog_active状态，再调大repl-backlog-size和client-output-buffer-limit，接着用SLOWLOGGET定位慢命令，最后校准Lettuce超时配置并排查大key。
