Redis技术文章
-
从循环 GET 多个 Redis key 导致接口变慢的现场开始，排查网络往返累积问题，再用 Pipeline、分批窗口和结果顺序对齐优化批量读写。436 收藏 -
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。433 收藏 -
SpringBoot中@Cacheable不支持动态过期时间，因SpringCache抽象层仅支持全局TTL配置；需通过RedisTemplate手动设expire、多CacheManager配置或自定义RedisCacheWriter实现差异化TTL。432 收藏 -
SINTER是Redis中计算共同好友唯一靠谱、原子、高效的方式，它基于内存集合运算，自动选取最小集合优化性能，毫秒级返回结果，避免网络往返与客户端计算开销。430 收藏 -
RedisPub/Sub不直接产生内存碎片，但未清理的订阅连接、消息积压或缓冲区配置不当会推高used_memory_rss，导致mem_fragmentation_ratio偏高，形成“假性碎片”；真实碎片源于键值对频繁增删改，而Pub/Sub缓冲区不受active-defrag影响。430 收藏 -
CLUSTERKEYSLOT仅执行CRC16(key)mod16384计算，返回0–16383的槽号，不查询集群拓扑或节点信息；定位具体实例需配合CLUSTERSLOTS或CLUSTERNODES查找槽所属节点。429 收藏 -
Redis6.2+需用--cluster参数运行redis-benchmark，否则MOVED/ASK重定向导致QPS归零；低版本需手动固定槽位或升级。428 收藏 -
allkeys-random并非真正无差别：它只在内存达限且写入触发时，从永不过期的主字典key中伪随机删除，不考虑访问频次、大小或热度，易误删热图；应改用allkeys-lru或ZSET+定时清理。427 收藏 -
Redis卡顿是设计使然，因其单线程模型下Lua脚本原子独占主线程，执行长耗时操作会阻塞所有请求，包括过期、AOF、心跳等；复杂聚合应迁出至应用层。424 收藏 -
XREADGROUP能自动负载均衡，因Redis服务端按轮询策略将新消息分发给组内不同消费者，确保同条消息仅投递一次；未ACK消息超时后可被其他消费者XCLAIM接管，实现故障转移。424 收藏 -
RedisCluster故障转移由主节点失联且多数主节点投票确认触发；从节点需满足复制偏移量达标、获多数主节点投票才能当选新主。423 收藏 -
dump.rdb文件越积越多是因为Redis默认不自动清理旧快照，每次bgsave生成新文件但保留旧文件，需依赖外部脚本按时间戳安全清理。422 收藏 -
必须分片，因单keyGEOADD底层ZSET会导致查询O(logN+M)延迟、RDB/AOFfork超时、无法水平扩展；应按Geohash前4-5位分key，查时用邻区算法并发查最多9个key并合并去重排序。418 收藏 -
Redis6.0+的Pub/Sub不阻塞主线程，因消息分发改由独立客户端上下文异步处理；而5.x及更早版本中publish同步遍历订阅者，网络慢或缓冲区满时会阻塞主线程。417 收藏 -
直接调大save触发阈值是最有效、最安全的手段，通过修改redis.conf中save配置项（如将save6010000改为save30050000），可降低RDB快照频率，缓解磁盘IO压力，但需结合数据丢失容忍度与写入节奏合理设置。417 收藏