- 为什么要使用Redis?
- 那些数据适合放入缓存？
一、缓存失效问题
1. 缓存穿透
指查询一个一定不存在的数据，由于缓存是不命中，将去查询数据库，但是
数据库也无此记录，我们没有将这次查询的null写入缓存，这将导致这个不
存在的数据每次请求都要到存储层去查询，失去了缓存的意义
风险：
利用不存在的数据进行攻击，数据库瞬时压力增大，最终导致崩溃
解决：
null结果缓存，并加入短暂过期时间
2. 缓存雪蹦
缓存雪崩是指在我们设置缓存时key采用了相同的过期时间，
导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时
压力过重雪崩。
解决：
原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这
样每一个缓存的过期时间的重复率就会降低，就很难引发集体
失效的事件。
3. 缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些
时间点被超高并发地访问，是一种非常“热点”的数据。如果这个key在大量请求同时进来前正好失效，那么所有对
这个key的数据查询都落到db，我们称为缓存击穿。
解决：
加锁
大量并发只让一个去查，其他人等待，查到以后释放锁，其他
人获取到锁，先查缓存，就会有数据，不用去db
二、分布式加锁
本地锁，只能锁住当前进程，所以我们需要分布式锁
-
分布式锁基本原理
我们可以同时去一个地方“占坑”，如果占到，就执行逻辑。否则就必须等待，直到释放锁。
“占坑”可以去redis，可以去数据库，可以去任何大家都能访问的地方。
等待可以自旋的方式。
1. 分布式锁演进-阶段一
问题：
setnx占好了位，业务代码异常或者程序在页面过程
中宕机。没有执行删除锁逻辑，这就造成了死锁
解决：
设置锁的自动过期，即使没有删除，会自动删除
2. 分布式锁演进-阶段二
问题：
setnx设置好，正要去设置过期时间，宕机。又死锁了。
解决：
设置过期时间和占位必须是原子的。redis支持使用setnx ex
命令
3. 分布式锁演进-阶段三
问题：
删除锁直接删除？？？
如果由于业务时间很长，锁自己过期了，我们
直接删除，有可能把别人正在持有的锁删除了。
解决：
占锁的时候，值指定为uuid，每个人匹配是自己
的锁才删除。
4. 分布式锁演进-阶段四
问题：
如果正好判断是当前值，正要删除锁的时候，锁已经过期，
别人已经设置到了新的值。那么我们删除的是别人的锁
解决：
删除锁必须保证原子性。使用redis+Lua脚本完成
5. 分布式锁演进-阶段五-最终形态
保证加锁【占位+过期时间】和删除锁【判断+删除】的原子性。
更难的事情，锁的自动续期
Lua脚本:
[图片上传中...(屏幕快照 2020-06-28 下午11.27.40.png-299051-1593358130785-0)]
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return
redis.call('del', KEYS[1]) else return 0 end";
三、缓存数据一致性
缓存里面的数据如何和数据库保存一致性？
- 双写模式
- 失效模式
采用方案： 失效模式
- 缓存的所有数据都有过期时间，数据过期下一次查询触发主动更新
- 读写数据的时候，加分布式读写锁。(如经常写，经常读会对系统造成影响。如偶尔写，经常读，无影响。因为读写锁最大的特定是：读相当于无锁状态，只有在写锁的情况下，读锁才需要等待。)
1. 双写模式
2. 失效模式
3. 解决方案
无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办？
• 1. 如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加
上过期时间，每隔一段时间触发读的主动更新即可
• 2. 如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式。
• 3. 缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
• 4. 通过加锁保证并发读写，写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。（业务不关心
脏数据，允许临时脏数据可忽略）；
总结：
- 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可。
- 我们不应该过度设计，增加系统的复杂性
- 遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。
4. 缓存一致性解决-Canal
Canal是阿里开源的中间件
