-
调小down-after-milliseconds并非提速关键,它仅控制单哨兵标记SDOWN的阈值;真正影响故障转移速度的是探测间隔、quorum共识、hello广播周期及failover-timeout与从节点同步能力的协同匹配。156 收藏 -
Redis碎片率超1.5时响应变慢甚至雪崩,根本原因是jemalloc在不连续空闲块中反复查找合适内存块,导致分配延迟升高、CPU波动、GC压力上升并可能引发级联雪崩。457 收藏 -
根本原因是JedisSentinelPool未真正启用自动发现机制;必须显式设置setTestOnBorrow(true)、传入至少两个可达哨兵地址、调大sentinelMonitorInterval,否则轮询不触发重建且DNS/连接复用导致持续连旧主。482 收藏 -
ZADD的score不能用时间戳,因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑;应使用业务分数(如积分)并利用ZADD覆盖更新、ZINCRBY原子累加、ZREM安全删除。183 收藏 -
Redis连接空闲后收不到数据主因是防火墙/NAT静默丢包,须主从节点均配置tcp-keepalive300并重启生效;该参数控制空闲300秒后发首探,不读取内核参数,需ss-tnp验证timer列是否显示keepalive。403 收藏 -
FUNCTIONLOAD将函数库作为数据库对象持久化并复制,SCRIPTLOAD仅内存缓存脚本且不落盘、不复制;前者支持高可用与跨节点复用,后者重启或主从切换后即失效。281 收藏 -
应立即将maxmemory-policy从allkeys-lru切回volatile-lru,但需先停写、确认内存未满,再执行CONFIGSET与REWRITE,并配合RDB恢复关键数据,否则残留无TTLkey将持续引发淘汰。232 收藏 -
RedisLua脚本需用原子“读-判-写”实现状态变迁,推荐HASH结构存储多字段(如status、updated_at、version),通过HGETALL/HSET原子操作,结合redis.call("TIME")获取时间戳、INCR或version校验防越级跳转,返回结构化结果便于业务判断。224 收藏 -
RedisTemplate操作Hash返回null的主因是序列化器不一致:key、hashKey、value三者序列化方式必须匹配,尤其hashKey须用StringRedisSerializer,value推荐Jackson序列化,否则反序列化失败或读不到数据。439 收藏 -
Redis6.0多线程不加速命令执行,仅I/O多线程+pipeline组合可提升导入效率;需客户端用pipeline打包发送,且主线程不饱和时才有效。406 收藏 -
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略:空值需设短过期并避免null值;布隆过滤器须预估容量、全局单例且配合写库更新;业务层应优先校验参数合法性。229 收藏 -
Redis6+的io-threads应设为2~8,不超过磁盘队列深度的2倍,且必须保持io-threads-do-readsno;它仅加速写入内核页缓存,不加速fsync,设得过多反而加剧IOWAIT和延迟。463 收藏 -
能,但仅限Redis服务器端EVAL/EVALSHA上下文;需用正确日志级别常量和预拼接字符串,且依赖redis.conf中loglevel和logfile配置生效。479 收藏 -
INFOkeyspace无法反映淘汰情况,因其仅统计存活key数量,不区分已过期未删除或已被淘汰的key,且不记录evicted_keys等关键淘汰指标。191 收藏 -
预热不充分指预热数据未覆盖真实热点、未执行完或未及时更新,导致上线后2–5分钟内缓存击穿;须用线上采样等动态数据源、分批超时控制、命中率校验及事件驱动机制。445 收藏