实际开发中缓存应用

缓存应该放在哪？

缓存作为分担数据库压力的NOSQL数据库，设置的位置正确，可以提高很多效率。但是，如果放的位置不正确，可能导致线上BUG。
一般来说，代码实现都是 先查缓存→有数据直接返回 →没有数据查询MySQL→设置缓存。
查询的话这种没问题。如果是高并发下修改数据呢？先更新数据库还是先淘汰掉旧的缓存？

1.先淘汰缓存

模拟一个场景，一个线程A修改数据（先淘汰缓存），另一个线程B访问数据
A线程淘汰缓存 → B线程访问数据 → B线程查询缓存中没有 → B线程去DB中查询，设置缓存（此时A线程还没更新DB中的数据） → A线程更新DB → 结束

这时，缓存中就是脏数据，后续的访问到的都是脏数据。这种情况在高并发情况下发生的概率还是很大的。

2.先修改DB

同样的场景，一个线程A修改数据（先更新DB）,另一个线程B访问数据
A线程修改DB → B线程访问，有缓存（旧的）→ A线程淘汰旧缓存

可以看出，这时不会出现先淘汰缓存那种方式的脏数据。但是也有一定的问题，在A更新完DB后B线程拿到的数据是更新前的，这个时间点的缓存和数据库中的数据不一致。这种影响一般也不大，我们大部分也是这么做的，起码不会导致缓存中有脏数据。

但是，如果在A更新完DB后，淘汰缓存时失效了，怎么办？不还是脏数据了？
①一般我们设置缓存的时候一定要设定过期时间，减小脏数据的影响范围。
②淘汰缓存失效时，发送一个MQ，用来淘汰缓存，但是这种成本较大（还要接入一个MQ，麻烦）
这时可以考虑 双淘汰缓存 机制

3.双淘汰缓存

同样的场景，一个线程A修改数据（双淘汰），另一个线程B访问数据
A线程淘汰缓存 → B线程访问，没有缓存，查DB（旧的），并设置缓存→ A线程修改DB →A线程淘汰缓存

这种方式，能够避免脏数据，同时，如果网络抖动导致连接缓存超时，大概率第一次淘汰缓存时就会报异常，取消更新DB。缺点是，每次更新，访问两次缓存，效率不如第二种。可以根据业务场景考虑使用哪种方式。

为什么不是更新缓存而是淘汰缓存？

模拟另一个场景，两个线程A、B同时更新数据。
并发情况下 ：A更新DB → B更新DB → B设置缓存 → A设置缓存

这时 DB中的money字段为 20，缓存中的money为10，会导致长时间的数据不一致，这种做法也比较危险。
如果非要使用设置缓存这种方式的话，一般要加上分布式锁。

缓存击穿

缓存击穿是指缓存失效，请求大量打到数据库上。
我们实现缓存的时候，一般在DB中查询出的值为非空（not null），才会设置缓存，正常这样是没问题的。
但是如果你的某个服务调用端出了问题，来查询一些你的表中本就不存在的数据，会导致所有请求都访问数据库，数据库有被压垮的风险，导致你的服务整体不可用。
方案：有这种风险的情况下，可以在查询出空值时也设置一个几秒的缓存。不用担心缓存脏数据的问题（缓存中的数据是null），只要在insert的时候，把这个值为null的缓存淘汰掉旧可以了。