如何保证缓存与数据库的双写一致性
- 先更新数据库，后更新缓存（不建议采用）
- - 原因一（会产生缓存与数据库数据不一致）：在==高并发==的场景下，如果同时有请求 `A` 和请求 `B` 进行获取数据，那么会出现
  - 原因二（业务场景角度）
- 先更新缓存，后更新数据库（不建议采用）
- 先删除缓存，后更新数据库（不太理想，可以采用）
- - 解决方案
  - - 为什么要休眠 `1` 秒钟，还要再次删除缓存
    - 那么这个 `1` 秒钟是怎么确定的
    - 那么采用延时双删策略，如第二次删除缓存失败怎么办
- 先更新数据库，后删除缓存（==建议采用==）
- - 那么采用==延时双删策略==时，如第二次删除缓存失败怎么办
  - - 方案一
    - 方案二

如何保证缓存与数据库的双写一致性

只要使用到缓存，无论是本地内存做缓存还是使用 redis 做缓存，那么就会存在缓存与数据库同步的问题，接下来就讨论一下关于保证缓存和数据库双写时的数据一致性

我们这里列出来所有策略，并且讨论他们优劣性

先更新数据库，后更新缓存（不建议采用）
先更新缓存，后更新数据库（不建议采用）
先删除缓存，后更新数据库（不太理想，可以采用）
先更新数据库，后删除缓存（建议采用）

先更新数据库，后更新缓存（不建议采用）

这套解决方案，大家普遍反对的，一般是没有人使用的

原因一（会产生缓存与数据库数据不一致）：在高并发的场景下，如果同时有请求 `A` 和请求 `B` 进行获取数据，那么会出现

请求 A 更新了数据库
请求 B 也更新了数据库
请求 B 更新了缓存
请求 A 更新了缓存

这就出现了请求 A 更新缓存应该比请求 B 更新缓存早才对，但是因为网络等原因，B 却比 A 更早更新了缓存。这就导致了脏数据，因此不考虑

原因二（业务场景角度）

如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能
如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合

先更新缓存，后更新数据库（不建议采用）

这套解决方案，一般是没有人使用的。也会出现上述情况

先删除缓存，后更新数据库（不太理想，可以采用）

该方案会导致 “缓存与数据库的数据” 不一致，原因：在高并发的场景下，如果同时有一个请求 A 进行写数据操作，请求 B 进行读数据操作，那么会出现

请求 A 开始进行写操作，删除缓存
此时请求 B 开始进行读操作，发现缓存没有数据
然后，请求 B 去数据库查询得到数据（得到的不是请求 A 写入的新数据，是旧数据，是脏数据）
请求 B 将拿到的数据写入缓存
此时，请求 A 才正式进行写操作

注意：在高并发的场景下，如果同时有一个请求 A 和请求 B 都进行写数据操作，那么是不会出现缓存与数据库数据不一致的情况的

解决方案

可以采用延时双删策略，伪代码如下

public void write(String key, Object data) {// 删除缓存 redis.delKey(key);// 再写数据库 db.updateData(data);// 线程休眠 1 秒钟 Thread.sleep(1000);// 再次删除缓存redis.delKey(key);
}

为什么要休眠 `1` 秒钟，还要再次删除缓存

这样可以使得请求 A 在写完数据时，可以将请求 B 写入缓存的脏数据删除掉

那么这个 `1` 秒钟是怎么确定的

针对上面的情形，读者应该自行评估自己的项目的读数据业务逻辑的耗时，然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百 ms 即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据

那么采用延时双删策略，如第二次删除缓存失败怎么办

具体解决方案，且看第四种的策略的解析

先更新数据库，后删除缓存（建议采用）

对于这种方案，在 《Cache-Aside pattern》 有提到，另外，知名社交网站 facebook 也在论文 《Scaling Memcache at Facebook》 中提出，他们用的也是先更新数据库，再删缓存的策略

那么采用延时双删策略时，如第二次删除缓存失败怎么办

提供一个保障的重试机制即可，这里给出两套方案

方案一

更新数据库数据
缓存因为种种问题删除失败
将需要删除的 key 发送至 MQ 消息队列
自己消费消息，获得需要删除的 key
继续重试删除操作，直到成功

然而，该方案有一个缺点，对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的 binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作

方案二

更新数据库数据
数据库会将操作信息写入 binlog 日志当中
订阅程序提取出所需要的数据以及 key
另起一段非业务代码，获得该信息
尝试删除缓存操作，发现删除失败
将这些信息发送至消息队列
重新从消息队列中获得该数据，重试操作

备注说明：上述的订阅 binlog 程序在 mysql 中有现成的中间件叫 canal，可以完成订阅 binlog 日志的功能。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路