前言
看到标题，可能小伙伴们会虎躯一震？
嗯？
难道不应该使用Redis做缓存？
答：
不是你想的那样，
只是说，有几种情况，使用缓存我们需要了解考虑周全，选择正确的使用姿势。
正文
好，我们进入该篇正题。
（一定要耐心结合我举例进行推演才能更加明白）
我们既然选择了缓存，用redis存储缓存数据，必然是为了一个字，快。
就是想避免每次都访问数据库，能直接从缓存很快地拿出数据。
那么，大家在使用缓存的时候，会不会冥冥之中有对数据的准确性有过怀疑？ 对数据的时效性有过质疑？
先列出，我们使用缓存的时候，会选择到的方式 四种：
（对于读操作，不用多言，那肯定是先读缓存，没有才从数据库获取。）
所以着重针对 写 操作 分析：
第一种：
先更新数据库，再更新缓存
第二种：
先更新缓存，再更新数据库
第三种：
先删除缓存，再更新数据库
第四种：
先更新数据库，再删除缓存
逐一分析可能存在的问题
先更新数据库，再更新缓存
存在问题1：
-假设原来的值是500，先需要更新数据库的值变为1000， 成功了； 数据库的值为 1000；
-接着就会去更新缓存， 因为未知原因（网络等），导致更新失败； 缓存的值为 500不变。
-那么读操作来了，先去缓存里面读数据，拿到的是 500， 无疑这是读到了旧的数据。
存在问题2：
高并发场景时，
-假设原来的值是500，线程A更新数据库的值变为1000， 成功了； 数据库的值为 1000，接着就准备去更新缓存；
-这时候，线程B来了，更新数据库的值变成200，接着就会去更新缓存；
-因为网络的波动原因，B线程从后追上A线程， 率先更新了缓存的值，200； 此时缓存数据为200，非常正确。
-但紧接着，A线程缓过神来了，把缓存的值更新为了1000；
-这时候，读操作来了，先读缓存，拿出来的值是1000，实际上应该是200，无疑这是读到了错误数据。
特别是写操作远大于读操作的项目场景， 这个还是很让人头疼的。
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
先更新缓存，再更新数据库
存在问题1：
-假设原来的值是500，先需要更新缓存的值1000，成功了；缓存的值为1000；
-接着就会去更新数据库， 因为未知原因（网络等），导致更新失败； 数据库的值为 500不变。
-那么读操作来了，先去缓存里面读数据，拿到的是1000，可是数据库是500 。无疑这是读到了错误数据。
因为数据库更新不成功，缓存的数据应该也是不可以成功的。
存在问题2：
高并发场景时，
-假设原来的值是500，线程A更新缓存的值变为1000，成功了；缓存的值为1000，，接着就准备去更新数据库；
-这时候，线程B来了，更新更新缓存的值变成200，接着就会去更新数据库；
-因为网络的波动原因，B线程从后追上A线程， 率先更新了数据库，200； 此时数据库数据为200。
-但紧接着，A线程缓过神来了，把数据库的值的值更新为了1000；
-此时此刻，缓存数据是200，数据库数据是1000； 读操作来了，无疑这是读到了错误数据。
特别是写操作远大于读操作的项目场景， 这个还是很让人头疼的。
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
看完上面2种情况，明显我们都知道，在高并发切写远多于读的时候，这两种情况都是很不可取的；
所以，就衍生出一个策略，在写操作的时候，不要去更新缓存，而且选择直接删除缓存。
更新缓存的操作，放在读操作进行；
读操作为：如果缓存有，读出；无，读出数据库的值，更新缓存。
ps：当然读多写少的场景，上面2种方式也都还行。
那就是 先删除缓存，再更新数据库 还是 先更新数据库，再删除缓存 这两个之间的抉择了。
先删除缓存，再更新数据库
存在问题1：
-假设原来缓存的值是500，数据库也是500；
-先删除缓存， 因为未知原因（网络等），导致更新数据库时失败；
-这时候，读操作来了，无影响，因为缓存没有，直接读数据库，正常；
-这时候，写操作又来，无影响，缓存已经没有，继续更新数据库，正常；
这么一看，好像还蛮不错！
然而并不然！因为删缓存的策略代替更新缓存，上面讲到了是把缓存写入操作给了读操作进行。
继续看高并发的场景。
存在问题2：
高并发场景时，
-假设原来缓存的值是500，数据库也是500；
-线程A删掉了缓存，正准备去更新数据库，把值变成1000；
-因为网络的波动原因线程A懵了，呆滞了；
-这时候，线程B来了，线程B进行的读操作，查询，一看缓存没数据了（被线程A删掉了），接着就去读数据库，值为500；
-线程B读完数据库的值500后，紧接着把数据写入缓存！ 此时缓存的数据是500；
-此时线程A缓过神来，更新数据库值为1000。
-此后，缓存的数据是500，数据库数据是1000， 无疑，又是存在错误数据！
特别是读操作远大于写操作的项目场景， 这个好像又开始很让人头疼了。
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
先更新数据库，再删除缓存
存在问题1：
-假设原来缓存的值是500，数据库也是500；更新数据库值变成1000，成功了；
-删除缓存失败，还是500；
-这时候，读操作来了，读出缓存的数据500，无疑这是读到了错误数据；
存在问题2：
高并发场景时，
-假设原来缓存的值是500，数据库也是500；
-线程A来了，更新数据库的值为1000，删除了缓存；
-这时候，线程B也来了，线程B是一个读操作，发现缓存没有，读取了数据库的值1000，然后准备写入缓存；
-因为网络的波动原因线程B懵了，呆滞了；
-这时候线程C来了，线程C更新数据库值为2000，然后很利索删除缓存（这时候其实本来就没缓存）；
-然后线程B缓过神来了，很利索把值1000写入了缓存。
-这时候，其他读操作来了，读出换成的数据1000，而数据库实际是2000，无疑这是读到了错误数据；
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
******************************************懒人手动分割线******************************************
？？？
嗯？什么？
一轮下来把四种姿势都看完了，发现都不好？？？
那咱们总得选一种用缓存啊？
如果项目场景是读多写少 ：
而且是并发不考虑的场景，其实更新缓存的方式也是能用一用，不过还是建议用下面的删除缓存的方式。
如果项目场景是写多读少 ：
其实这时候,使用删除缓存的策略显然好很多。
先删除缓存，再更新数据库 分析：
那么选择 如果 先删除缓存，再更新数据库 ，上面提到了，就是怕高并发的场景，导致数据库的数据是正常的，而缓存的数据是不对的。
既然是因为这个缓存数据是脏的，那么针对这个问题，于是乎有了 延时双删除策略：
先删除 缓存 ，再更新数据库， 延时后再删除缓存
从字面上其实已经能知道，就是补一刀把后续的脏缓存数据删掉，这么具体的延时时间是多少，就得根据具体项目业务时间去衡量了。
先更新数据库，再删除缓存 分析：
那么选择 如果 先更新数据库 ，再删除缓存 ，其实这个方式是 一个国外比较推荐的使用缓存方式 ： Cache-Aside pattern
上面提到了，这种方式在高并发的场景也是存在问题的。
但是为什么外国人这么推荐这种方式呢？
回顾这种方式，在高并发的情形，出现问题的原因是 读操作的后面写入数据到缓存的环节上。
但是读操作实际上肯定比写操作快得多，所以发生上边描述的出现脏数据的场景的概率也是比较小。
每次读操作的时候最后会将数据库数据写到缓存， 而写操作最后会删除调缓存。
我们想象下，读非常快，写稍微慢的场景， 这样就算有读操作写入的旧的缓存数据，也会被慢写操作的删掉。
这样碰巧发生出现不一致数据的概率就会小很多，这也是外国人推荐的原因。
最后来一个个人的总结：
并发稍微低，那么我们可以用 先删除缓存，再更新数据库 再配上延时双删除策略。
并发稍微高，那么我们可以用 Cache-Aside pattern ， 先更新数据库 ，再删除缓存 。
其实看完这篇的，大家都知道，脏数据 在不适用 分布式锁 或者 其他能保证数据顺序的方法的情况下，都是存在的。
只不过是出现这种脏数据的概率以及严重性，是否是项目的业务需求可以接收。
对于该篇文章分析存在的问题，都是有额外的补救方法，如加锁，重试，消息队列等等
好，该篇介绍就到此吧。
