Redis缓存一致性问题处理方案
- 由缓存的调用者,在更新数据库的同时更新缓存
- 缓存与数据库整合为一个服务,由服务来维护一致性,调用者调用该服务,无需关心缓存一致性问题
- 调用者只操作缓存,由其他线程异步的将缓存数据持久化到数据库,保证最终一致性
操作缓存和数据库时有三个问题需要考虑:
1. 删除缓存还是更新缓存?
- 更新缓存:每次更新数据库都更新缓存,无效写操作较多
- 删除缓存:更新数据库时让缓存失效,查询时再更新缓存
2. 如何保证缓存与数据库的操作的同时成功或失败?
- 单体系统:将缓存与数据库操作放在一个事务
- 分布式系统,利用TCC等分布式事务方案
3. 先操作缓存还是先操作数据库?
- 先删除缓存,再操作数据库
- 先操作数据库,再删除缓存
缓存更新策略的最佳实践方案:
1. 低一致性需求:使用Redis自带的内存淘汰机制
2. 高一致性要求:主动更新,并以超时剔除作为兜底方案
- 读操作:缓存命中直接返回;缓存未命中则查询数据库,并写入缓存,设定超时时间
- 写操作:先写数据库,然后再删除缓存;要确保数据库与缓存操作的原子性
缓存穿透
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会打到数据库。常见的解决方案有两种:
1. 缓存空对象
- 优点:实现简单,维护方便
- 缺点:额外的内存消耗;可能造成短期的不一致
2. 布隆过滤
- 优点:内存占用较少,没有多余key
- 缺点:实现复杂;存在误判可能
3. 增强id的复杂度,避免被猜测id规律
4. 做好数据的基础格式校验
5. 加强用户权限校验
6. 做好热点参数的限流
缓存雪崩
缓存雪崩是指在同一时段大量的缓存同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力
解决方案:
- 给不同的Key的TTL添加随机值
- 利用Redis集群提高服务的可用性
- 给缓存业务添加降级限流策略
- 给业务添加多级缓存
缓存击穿
缓存击穿问题也叫热点Key问题,就是一个被高并发访问并且缓存重建业务较复杂的key突然失效,无数的请求访问会在瞬间给数据库带来巨大的冲击。
常见的解决方案有两种:
1. 互斥锁
优点:
- 没有额外的内存消耗
- 保证一致性
- 实现简单
缺点:
- 线程需要等待,性能受影响
- 可能有死锁风险
2. 逻辑过期
优点:线程无需等待,性能较好
缺点:
- 不保证一致性
- 有额外内存消耗
- 实现复杂
多线程并发安全问题
悲观锁
认为线程安全问题一定会发生,因此在操作数据之前先获取锁,确保线程串行执行。例如synchrinized、lock都属于悲观锁。
- 优点:简单粗暴
- 缺点:性能一般
#单体架构基于事务的悲观锁方案
public void main(String[] args) {
Long user;
synchronized (user.toString().intern()){
UserService proxy