-
ZREMRANGEBYSCORE默认闭区间,需用“(”语法实现开区间;误删风险高,执行前须用ZRANGEBYSCORE预查;大ZSet范围删除应分批处理,Redis7.0+支持LIMIT,旧版需客户端循环;ZREMRANGEBYRANK与ZREMRANGEBYSCORE语义不同,不可混用。
-
执行replicaofnoone再replicaof不会清空从库数据,仅切换复制源;真正全量同步需确保无运行复制流且master_replid/offset不匹配,必要时手动清空或重启从库。
-
增大repl-backlog-size能修复断连后全量回滚,因其为主节点提供足够大的环形缓冲区暂存断连期间的写命令;只要从节点重连时请求的slave_repl_offset仍在该缓冲区内(即master_repl_offset−slave_repl_offset≤repl_backlog_histlen),即可触发PARTIALRESYNC实现增量同步,避免FULLRESYNC。
-
调小down-after-milliseconds并非提速关键,它仅控制单哨兵标记SDOWN的阈值;真正影响故障转移速度的是探测间隔、quorum共识、hello广播周期及failover-timeout与从节点同步能力的协同匹配。
-
Redis碎片率超1.5时响应变慢甚至雪崩,根本原因是jemalloc在不连续空闲块中反复查找合适内存块,导致分配延迟升高、CPU波动、GC压力上升并可能引发级联雪崩。
-
根本原因是JedisSentinelPool未真正启用自动发现机制;必须显式设置setTestOnBorrow(true)、传入至少两个可达哨兵地址、调大sentinelMonitorInterval,否则轮询不触发重建且DNS/连接复用导致持续连旧主。
-
ZADD的score不能用时间戳,因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑;应使用业务分数(如积分)并利用ZADD覆盖更新、ZINCRBY原子累加、ZREM安全删除。
-
Redis连接空闲后收不到数据主因是防火墙/NAT静默丢包,须主从节点均配置tcp-keepalive300并重启生效;该参数控制空闲300秒后发首探,不读取内核参数,需ss-tnp验证timer列是否显示keepalive。
-
FUNCTIONLOAD将函数库作为数据库对象持久化并复制,SCRIPTLOAD仅内存缓存脚本且不落盘、不复制;前者支持高可用与跨节点复用,后者重启或主从切换后即失效。
-
应立即将maxmemory-policy从allkeys-lru切回volatile-lru,但需先停写、确认内存未满,再执行CONFIGSET与REWRITE,并配合RDB恢复关键数据,否则残留无TTLkey将持续引发淘汰。
-
RedisLua脚本需用原子“读-判-写”实现状态变迁,推荐HASH结构存储多字段(如status、updated_at、version),通过HGETALL/HSET原子操作,结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转,返回结构化结果便于业务判断。
-
RedisTemplate操作Hash返回null的主因是序列化器不一致:key、hashKey、value三者序列化方式必须匹配,尤其hashKey须用StringRedisSerializer,value推荐Jackson序列化,否则反序列化失败或读不到数据。
-
Redis6.0多线程不加速命令执行,仅I/O多线程+pipeline组合可提升导入效率;需客户端用pipeline打包发送,且主线程不饱和时才有效。
-
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略:空值需设短过期并避免null值;布隆过滤器须预估容量、全局单例且配合写库更新;业务层应优先校验参数合法性。
-
Redis6+的io-threads应设为2~8,不超过磁盘队列深度的2倍,且必须保持io-threads-do-readsno;它仅加速写入内核页缓存,不加速fsync,设得过多反而加剧IOWAIT和延迟。