Redis高并发缓存架构

场景1：秒杀库存场景， 10000人抢100个商品

如果用普通的分布式锁实现， 最后抢到的人，要等前面99个人抢完

优化方案：可用分段锁， 降低锁的粒度， 比如1-10库存用锁product:101_1,11-20库存用锁product:101_2等， 提高并发性能

场景2: 商品的增删改查,如何用高并发缓存架构实现?针对各种并发场景,如何优化

查询：先从缓存获取，缓存没有查库， 查到库之后放入缓存

新增/修改：取数据库更新货品，删除缓存

问题1：99%的商品都是冷门商品， 不应该全部放在redis缓存

解决：设置缓存有效期， 例如一天，每次查询时将锁延期（ttl命令很快）， 实现冷热数据分离。如果每天访问的热数据还是很多， 可以用缓存淘汰策略。

问题2： 缓存击穿。例如某些批量操作， 批量查库， 批量放缓存一天， 缓存同时过期， 下次批量操作时， 大量请求直接打到数据库，数据库顶多只能扛几万的qps

解决：缓存过期时间加上随机数， 分散过期， 分散查库压力

问题3： 缓存穿透。

例如某个热门商品被后台小二误删， 客户端还有很多人访问，会有大量请求持续打到数据库；

例如黑客攻击，浏览器编辑url访问一个不存在的商品id，

解决：

• 将不存在商品缓存NULL, 下次直接从缓存拿
• 布隆过滤器

问题4：黑客用脚本批量访问很多不存在的商品id，导致Redis缓存很多不存在的值是NULL商品

解决：NULL商品缓存有效期可以设置短一点， 例如1分钟

问题5: 热点key重建

前提:

• 当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
• 重建缓存不能在短时间完成， 可能是一个复杂计算， 例如复杂的SQL、 多次IO、 多个依赖

缓存失效的瞬间， 会有大量线程来重建缓存， 造成后端负载加大， 可能会让应用崩溃

解决: 分布式锁+双重检查.查数据库之前加一把分布式锁, 获取锁成功后, 再去缓存检查一遍, 缓存没有再去查库. 

问题6: 缓存雪崩

如果发生以下场景, 导致大量请求直接打到数据库, 引起系统负载暴增, 性能下降甚至瘫痪

• 在某个时间点，缓存中的大量数据同时过期失效。
• Redis宕机

解决:

• 限流
• 缓存加随机时间
• 用多级缓存, 例如再加一层JVM缓存,encache设置过期时间, mq广播更新本地缓存
• 热点缓存系统, 客户端只查JVM缓存, 服务端更新JVM缓存

问题7: 缓存双写不一致

1. 双写不一致

2. 读写不一致

线程3如果在查数据库和写缓存中间卡顿, 如果这时候线程2写数据, 线程3再去更新缓存, 就会缓存脏数据.

解决:

1. 并行转串行
2. 延迟双删, 等待50ms后删除, 缺点是少概率事件影响接口性能
3. 读多写少时候, 用redisson读写锁, 读写互斥, 读读不互斥(推荐)
4. 读多写多时候, 不建议用缓存

问题8: 重建热点缓存key时, 分布式锁还能优化吗?

解决: 如果确定重建缓存大概需要的时候, 可用tryLock代替lock, 串行转并发.但是要考虑tryLock失败问题, 比如递归重新查或者返回错误码友好提示.