redis_note_07_使用

redis缓存使用问题

击穿

现象: 大量客户访问某个热key, 由于key刚好过期/淘汰, 大量请求绕过redis, 直接落到数据库上; 导致数据库瞬间压力过大

问题: 大量并发绕过缓存, 对数据库压力;
处理: redis6.x之前为单进程单实例处理读写操作, 大量读同一key请求在redis队列中排队; 这时第一个请求未查询到key, 那么就可以设置一把锁( setnx() ), 只有第一个请求获取到这把锁, 可以访问数据库并加载缓存, 加载完成后再释放锁(同时设置过期时间, 避免死锁); 后续请求未获得锁, 进行等待;

引入问题: 假如数据库拥塞, redis在过期时间内没处理完成, 锁释放; 则后续请求会继续申请锁, 释放, 等待; 导致一定的请求最终处于对数据库等待状态
处理: 根据过期时间设置, 评估等待的数量是否在接受范围内; 如果不在, 可以新增线程对持有锁进程活跃状态的监控, 如进程未出现异常, 且锁状态未被更新, 表示持有锁的进程在等待数据库操作, 那么对锁进行续租(延长过期时间)

穿透

现象: 从业务接受到的查询是业务系统中根本不存在的数据(既不存在缓存中, 也不存在数据库中)
处理: 布隆过滤器(方案1: client端包含布隆过滤器; 方案2: client仅集成算法, server端使用bitmap(无状态); 方案3: server端直接集成布隆过滤器模块(redis安装))
问题: 布隆过滤器不支持删除操作, 可以使用布谷鸟过滤器(空key)

雪崩

现象: 大量的缓存key同时失效, 客户大量的请求直接到了数据库, 导致数据库压力过大
处理: 与时点性无关的数据, 随机过期时间; 与时点性有关(隔日数据需要更新清理); 方案1: 凌晨更新对应缓存, 同时业务层加操作, 在更新缓存期间(比如凌晨)随机延时, 不让大量请求同时到数据库; 方案2: 业务层随机延时(将不同或相同key的并发削峰), 同时依赖击穿的解决方案, 通过加锁来处理同一key的大量查询问题

分布式锁(强一致性锁可以使用zookeeper)

使用方式: (可以使用 redisson)

1. setnx
2. 设置过期时间
3. 守护线程(多线程)延长过期时间(续租)
4. 保证锁删除操作原子性(key删除通过lua脚本, 判断存在则删除)