缓存常用的读写策略
缓存与DB的数据不一致问题，大多数都是指DB的数据已经修改，而缓存中的数据还是旧数据的情况。
旁路缓存模式
对于读操作：基本上所有模式都是先尝试从缓存中读，没有的话再去DB读取，然后写到缓存中
对于写操作：先更新数据，再删除旧缓存
为什么先修改数据库，而不是先删除缓存？
如果是先删除缓存的话，很容易引起数据不一致的问题。
比如写操作的过程中来了个读操作。在删除完缓存但数据库没有修改完的期间，来了个读请求，它就会把没有修改的数据进行缓存，后续再更新数据库之后，数据库的内容和缓存的内容就不一致了。
同样地，读取操作的过程中（DB读完了，但没有写入缓存中）来了个写请求，把DB数据改了，那么最终写入的缓存将会是旧的数据，因为DB已经被更新了。（只不过这次情况概率小，因为写入缓存的速度特别快，期间DB的数据很难被修改完成）
为什么修改数据库后要删除缓存，不能修改完数据库后直接修改缓存吗？
不能，在高并发场景下，同时处理多个写请求，如果某个写请求中间，完成了另外一个写请求，那么最后更新的缓存就会是旧的数据。但如果是先更新数据库，再删除缓存的话就不用考虑这么多了，因为下次访问会重新加载最新数据。
这种模式会有一致性问题吗，举个例子？
也会有的，但是概率比较小，具体如下：
- 第一种情况，写操作的过程中来了读请求。更新完DB但缓存没有删掉的期间，如果来了一个读请求，此时会命中缓存，读取到的是缓存中的旧数据，但是这个缓存马上会被删掉，影响几乎可以忽略不计。
- 第二章情况，读操作的过程中来了个写请求。请求1读取了DB的值，准备写入缓存但还没有写入，此时如果来了个写请求，将DB的数据修改了，那么之前读请求写入的缓存就是过期的缓存了。不过这种情况概率也比较小，因为写缓存的速度非常快，写缓存的期间数据被修改不太可能（除非高并发场景）。
解决方案，使用分布式锁保证更新DB和删除缓存的操作同步进行，不会受其它线程影响。
特点：
- 实现简单，能保证最终一致性
- 所有数据的首次读取都要经过DB，之后才能命中缓存（可以将热点数据可以提前放入 cache 中）
- 写操作比较频繁的话导致 cache 中的数据会被频繁被删除，会影响缓存命中率
适用场景：读多写少（大多数场景）、不需要保证和数据库的强一致性
注意：根据CAP理论，如果需要数据库和缓存数据保持强一致，就不适合使用缓存，换句话说用：用缓存的本质就是牺牲一致性去换速度。
读写穿透模式
旁路缓存模式是由用户去分别控制cache和DB的读写，而读写穿透是由cache服务去直接完成对DB的读写，这样减轻了程序员的职责，但是Redis没有提供直接将缓存数据写入DB的功能，所以比较少见。
对于读操作：也是先去缓存中找，然后再去DB中找，唯一不同的就是从DB找的过程是由cache程序自动进行的。
对于写操作：在更新DB的同时也更新cache本身（而不是删除），这个步骤是由缓存服务去实现的。
适用场景：需要保证数据的强一致性
缺点
- 使用要求高，要求缓存程序对自身修改时能同步对DB进行更新，Redis就不支持
异步写入模式（写后模式）
也是由 cache 服务来负责 db 的读写，更新数据时先更新缓存中的数据，然后过一段时间再异步批量去更新db，常用在实时变化且又是非核心的数据中，比如点赞量、阅读量等等。
适用场景：对响应速度要求很高，但对一致性要求不高
缺点：如果写入DB前缓存挂了，数据就会丢失
