Redis技术文章
-
Redis内存未立即下降是因为采用惰性+定期双机制清理过期key，定期清理受hz参数控制；hz越大扫描越频繁但CPU开销越高，默认10，调至100可加速清理，超100收益递减且可能引发高CPU。234 收藏 -
会，Redis主从同步常打爆网卡，尤其跨机房、大key迁移或全量复制时；因Redis无带宽限速参数，需用tc对主节点6379端口出向流量限速，并调大repl-timeout防超时断连。233 收藏 -
String类型在LRU驱逐场景下内存效率低，因其每个key和value均独立占用redisObject+SDS结构，导致对象头冗余高、驱逐粒度粗；而Hash等结构共享key对象头、支持ziplist压缩，内存利用率高40%~60%。233 收藏 -
RedisAOF是将写命令追加到文件以实现持久化，但并非所有场景都适用：appendfsync配置影响安全性与性能，everysec是线上折中选择，always性能差，no不可靠；AOF重写可能耗资源，切换时需检查文件完整性、路径及时间戳。232 收藏 -
OBJECTFREQ返回key的LFU近似频次（0–255），多次GET后应上升；频次非线性增长、有衰减、依赖serverCron更新，需确认Redis≥4.0、maxmemory-policy正确配置且内存压力存在。232 收藏 -
单靠Redis命令无法保证双写缓存原子性，因SET和DEL是两个独立命令，中间可能被其他客户端插入操作，导致缓存与DB不一致；Lua脚本在服务端单线程原子执行，可规避竞态。232 收藏 -
应立即将maxmemory-policy从allkeys-lru切回volatile-lru，但需先停写、确认内存未满，再执行CONFIGSET与REWRITE，并配合RDB恢复关键数据，否则残留无TTLkey将持续引发淘汰。232 收藏 -
Redis的String类型加剧内存碎片是因为频繁SET/GET/APPEND导致jemalloc中大小不一的内存块反复分配释放，旧块无法复用而残留为碎片，表现为mem_fragmentation_ratio>1.5且used_memory_rss远大于used_memory。230 收藏 -
缓存空值、布隆过滤器和业务层校验是防御缓存穿透的三层策略：空值需设短过期并避免null值；布隆过滤器须预估容量、全局单例且配合写库更新；业务层应优先校验参数合法性。229 收藏 -
布隆过滤器必须前置到请求入口，如Web中间件或API网关，在接触Redis或数据库前完成校验；冷启动需预热合法ID，误判率宜设为1%；空值缓存须存"NULL"字符串并设5–300秒短过期；参数校验需在网关/Controller层强校验；需监控空值占比与误判率并告警。228 收藏 -
RedisBitmap更新必须用Pipeline，因单次SETBIT网络开销大，10万次独立调用耗时超8秒，Pipeline可压至300ms内，并需显式execute()提交；offset须紧凑映射，key命名要可排序，BITOP前应校验长度，回滚靠双写+原子RENAME。227 收藏 -
RedisPub/Sub不适合生产实时报警系统，因其消息零持久化、无消费确认与重试机制，订阅者断线或处理失败即导致报警永久丢失。227 收藏 -
必须同时排除RedisAutoConfiguration和RedisRepositoriesAutoConfiguration，否则因后者依赖redisTemplate而启动失败；exclude参数需传入Class数组，配置文件中须正确书写全限定名并避免缩进错误，且需清理残留Redis属性和手动Bean。227 收藏 -
LTRIM是限制RedisList长度的唯一可靠方式，因其原子性、精准截断和内存即时释放特性；必须配合LPUSH使用，错误参数会清空列表，高并发下推荐Lua脚本保障原子性。225 收藏 -
哨兵选主失败或频繁切换的根本原因是时钟偏差过大或网络单向隔离；需先用ntpstat和chronyctracking检查时钟同步，再用tcpdump验证26379端口双向通信，最后才调整哨兵参数。224 收藏