Redis的生产问题-缓存雪崩-缓存穿透-双写一致性--并发竞争

Redis

生产问题

缓存雪崩

现象

1. 缓存挂掉了，请求直接打到数据库上，导致数据库也直接挂掉了

解决方案

1. 事前：redis高可用，主从架构
2. 事中：本地缓存、hystrix。到数据库的请求不能超过某个阈值
3. 事后：需要做持久化，快速启动redis恢复
   
   

如何应对缓存穿透

现象

查询某个数据库肯定没有的数据，比如id是负数的

因为数据库没有，肯定不会保存到缓存上面，所以都会走库，这时候数据库压力就特别大

解决方案

1. 不存在的值也存到缓存中
2. 布隆过滤器，bitmap

双写一致性

cache aside pattern(普通模式)

1. 读的时候，缓存有数据就返回，没有走数据库–插入缓存–返回
2. 更新的时候，删除缓存，更新数据库
3. 更新先删的原因：某些value是多个表联合查询出来的，比如通过一些计算算出来
4. 更新先删的原因2：频繁修改，读比较少，lazy加载的思想

读写并发情况下的情景

1. 数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改
2. 读取更新并发情况下

解决

1. 串行化
2. 在服务中搞一些消息队列，根据主键hash 找到处理的队列
   

问题

1. 读请求长时阻塞
2. 读请求并发量过高
3. 多服务实例部署的请求路由
4. 热点商品的路由问题，导致请求的倾斜

并发竞争

现象

1. 多服务并发写
2. 多服务并发读

解决

分布式锁+时间戳

分布式锁确保同一时间只有一个实例在操作

时间戳用来判断是否需要插入，旧的话就不插入了

结合实际

1. 主从模式，开启rdb和aof
2. 数据大概小几十M