-这时候，线程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；
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
-此时此刻，缓存数据是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
上面提到了，这种方式在高并发的场景也是存在问题的。
但是为什么外国人这么推荐这种方式呢？
回顾这种方式，在高并发的情形，出现问题的原因是 读操作的后面写入数据到缓存的环节上。
但是读操作实际上肯定比写操作快得多，所以发生上边描述的出现脏数据的场景的概率也是比较小。
每次读操作的时候最后会将数据库数据写到缓存， 而写操作最后会删除调缓存。
我们想象下，读非常快，写稍微慢的场景， 这样就算有读操作写入的旧的缓存数据，也会被慢写操作的删掉。
这样碰巧发生出现不一致数据的概率就会小很多，这也是外国人推荐的原因。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
