通过本文档，你将会了解到
- 为什么要使用缓存
- 本地缓存它不香么？为什么要使用redis缓存，
- 缓存一致性问题，缓存穿透、击穿、雪崩解决方式。
1.为什么要使用缓存？
为了系统性能的提升，我们一般都会将部分数据放入缓存中，加速访问。而 db 承担数据落 盘工作。
1.1哪些数据适合放入缓存?
即时性、数据一致性要求不高的
访问量大且更新频率不高的数据(读多，写少)
举例:电商类应用，商品分类，商品列表等适合缓存并加一个失效时间(根据数据更新频率 来定)，后台如果发布一个商品，买家需要 5 分钟才能看到新的商品一般还是可以接受的
注意:在开发中，凡是放入缓存中的数据我们都应该指定过期时间，使其可以在系统即使没有主动更新数据也能自动触发数据加载进缓存的流程。避免业务崩溃导致的数据永久不一致 问题。
//从缓存加载数据
data = cache.load(id);
If(data == null){
//从数据库加载数据
data = db.load(id);
//保存到 cache 中
cache.put(id,data);
}
return data;
1.2 缓存失效的问题
1.2.1 缓存穿透
缓存穿透是指查询一个一定不存在的数据。
由于缓存是不命中，将去查询数据库，但是数据库也无此记录，我们没有将这次查询的 null 写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能 DB 就挂掉了，要是有人利用不存在的 key 频繁攻击我们的应用，这就是漏洞。
解决方法：缓存空结果、并且设置短的过期时间。
1.2.2 缓存雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间
导致缓存在某一时刻同时失效，请求全部转发到 DB，DB 瞬时压力过重雪崩。
解决方法：原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
1.2.3 缓存击穿
对于一些设置了过期时间的 key，如果这些 key 可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。
这个时候，需要考虑一个问题：如果这个 key 在大量请求同时进来前正好失效，那么所有对这个 key 的数据查询都落到 db，我们称为缓存击穿。
解决方法：加锁。大量并发只让一个人去查，其他人等待，查到之后释放锁，其他人获取到锁，先查缓存，就会有数据，不用去查数据库。
1.3缓存一致性的问题
1.3.1 双写模式
方案一：更新缓存，更新数据库
这种方式可轻易排除，因为如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致。
方案二：更新数据库，更新缓存
这种缓存更新策略俗称双写，存在问题是：并发更新数据库场景下，会将脏数据刷到缓存
方案三：删除缓存，更新数据库
存在问题：更新数据库之前，若有查询请求，会将脏数据刷到缓存
该方案会导致请求数据不一致
- 请求A进行写操作，删除缓存
- 请求B查询发现缓存不存在
- 请求B去数据库查询得到旧值
- 请求B将旧值写入缓存
- 请求A将新值写入数据库
上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。
方案四：更新数据库，删除缓存
存在问题：在更新数据库之前有查询请求，并且缓存失效了，会查询数据库，然后更新缓存。如果在查询数据库和更新缓存之间进行了数据库更新的操作，那么就会把脏数据刷到缓存
举例：如果在查询数据库和放入缓存这两个操作中间发生了数据更新并且删除缓存，那么会有旧数据放入缓存。
假设有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生缓存刚好失效
- 请求A查询数据库，得一个旧值
- 请求B将新值写入数据库
- 请求B删除缓存
- 请求A将查到的旧值写入缓存
更新缓存还是删除缓存？
如果更新缓存开销较小并且读多写少，基本不会有写并发的时候可以才用更新缓存，否则通用做法还是删除缓存
延迟双删
采用更新前后双删除缓存策略
public void write(String key,Object data){
redis.del(key);
db.update(data);
Thread.sleep(1000);
redis.del(key);
}
这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
删除缓存重试机制
不管是延时双删还是Cache-Aside的先操作数据库再删除缓存，如果第二步的删除缓存失败呢，删除失败会导致脏数据哦~ 那删除失败扔到消息队列里面继续删呗
binlog同步机制
首先，我们要明确一点，缓存不是更新，而应该是删除。
- 在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。你取出来后，一顿操作猛如虎，搞了1分钟，算出来了，然后放入缓存。更新缓存的代价有时候是很高的。一个缓存涉及的表的字段，在 1 分钟内就修改了 20 次，或者是 100 次，那么缓存更新 20 次、100 次；但是这个缓存在 1 分钟内只被读取了 1 次，有大量的冷数据。实际上，如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。用到缓存才去算缓存
- 懒加载思想：其实删除缓存，而不是更新缓存，就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。
删除缓存有两种方式：
先删除缓存，再更新数据库。解决方案是使用延迟双删。
先更新数据库，再删除缓存。解决方案是消息队列或者其他binlog同步，引入消息队列会带来更多的问题，并不推荐直接使用。
针对缓存一致性要求不是很高的场景，那么只通过设置超时时间就可以了。
- 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可。
- 我们不应该过度设计，增加系统的复杂性
- 遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。
一句话点名中心思想：要使用删除缓存+过期时间。正常用就行了，不用考虑这么多
2、本地缓存
本地缓存保存到内存里面，它不香么，挺香的。
但是本地缓存存在两个问题：
- 分布式的情况下这是三台机器，第一次去了1号，没有缓存加入缓存。第二次LB到了2号，那么没有缓存，又加一次。第三次LB到了3号。。。。
- 修改情况：LB到了1号修改了缓存。从此以后只有1号机器的缓存是正确的。2号3号缓存都是数据不一致问题。
所以最致命的就是修改的情况喽，第一点其实不算问题
拓展：rocketmq，nameserver本身无状态，相关组件的状态信息不会持久化，存储在内存中，但它本身支持配置参数的持久化，这个一般用不到。you see see 人家就是放入本地缓存，有删除、增加操作，难道它没问题？还真没问题，感兴趣的可以看看王者玩家都是怎么玩的。