背景

在高并发的业务场景中，因为MySQL数据库是操作磁盘效率比较低，因此大多数情况下数据库都是高并发系统的瓶颈。因为Redis操作数据是在内存中进行，所以就需要使用Redis做一个缓存。让请求先访问到Redis，而不是直接访问MySQL数据库。效果图如下

查询数据

上面的业务场景，就是一个典型的MySQL存储数据和Redis缓存数据的业务场景。下面来看看一般的查询流程，如下图：

上面的查询流程如下：

1. 用户请求系统，系统先查询Redis中是否有数据？
2. 如果Redis中有数据，则直接将缓存中的数据响应给用户。
3. 如果Redis中没有数据，则取查询MySQL数据库中是否有数据？
4. 如果MySQL中有数据，则先将数据更新到Redis中，再将数据响应给用户。
5. 如果MySQL中没有数据，则响应空数据给用户，请求结束。

上面的查询流程很简单，通过先查Redis缓存，避免大量请求访问MySQL数据库，从而大大提高系统响应效率。而且如果Redis中没有而MySQL中有，当从MySQL拿到数据以后，先将数据更新到Redis缓存中，这样下次请求同一份数据的时候就能从Redis中获取了。

更新数据

上面的查询流程是没什么问题，可是数据很有可能会更新。那么更新的时候怎么操作才能保证Redis和MySQL中的数据都更新成功并且一致呢？

下面看看一种常用的解决方案（双删缓存）：

第一个问题：为什么是删除Redis缓存数据而不是更新数据？

假设我们缓存的数据是要做一个很复杂的计算，而且还不一定能用到。那如果你更新MySQL数据之后去更新Redis缓存不是就很耗时了，而且有可能做无用功。

第二个问题：为什么是先删除Redis缓存数据而不是先更新数据库呢？

我们不妨假设先更新MySQL中的数据，然后再删除缓存。如果更新完MySQL但是删除Redis失败了（别问为什么会失败？系统故障行不行，全球断电行不行？），那下次查询请求过来，因为Redis中有缓存数据，所以直接返回服务器托管Redis缓存的旧数据了，是不是就出问题了？

那我们再看看，如果先删除Redis缓存，再更新MySQL。如果删除完Redis成功，但是更新MySQL失败。下次查询的时候，查询到Redis缓存发现没有，再去查MySQL，然后更新到Redis，虽然MySQL更新失败了，但是Redis中的数据和MySQL是一致的。

第三个问题：为什么更新完MySQL后还要再删一次Redis缓存呢？

假设我们第一次删完Redis结束，正在更新MySQL但是还没更新成功的时候，这时候有另外一个请求来查询数据。第二个请求查询Redis没有，然后查询MySQL这时候因为MySQL还没更新完，所以查询到的还是旧数据，同时把旧数据更新到Redis中了，等下一个请求再来查询的时候发现Redis有数据，就直接返回旧数据了。

因此更新完MySQL后需要再次删除Redis缓存。这样即使更新数据中间有其他个请求把旧数据更新到Redis中了，因为再次删了Redis缓存中的旧数据，依然能够避免其他请求获取到旧数据。

❝

我们认为数据是否更新成功是以MySQL中服务器托管的数据为准，因此MySQL还没更新完成前或者更新失败，获取到旧数据不算是问题。所以我们只要保证Redis和MySQL中的数据一致就行。

❞