前言
日常开发中常会使用redis作为项目中的缓存，只要我们使用 Redis 缓存，就必然会面对缓存和数据库间的一致性保证问题。而且如果数据不一致，那么应用从缓存中读取的数据就不是最新数据，可能会导致严重的业务问题。
为什么会数据不一致
数据一致性：指的是redis缓存跟数据库的数据的一致。假如缓存中没有数据，那么数据库的值必须是最新的。如果缓存中有数据，那么缓存中的值需要跟数据库的值相同。
理解完上述数据一致性的前提，我们看下什么情况下会导致缓存跟数据库的数据不一致。
- 并发更新问题：当多个客户端同时对同一个数据进行更新时，假设有两个客户端同时读取了数据库中的数据，然后对其进行了修改，并分别将修改后的数据存入缓存。因为两个客户端并不知道对方的修改，所以会导致缓存中存储的数据和数据库中的数据不一致。
- 异常情况：在更新缓存的过程中，如果发生了错误或者异常，可能导致缓存更新失败，从而导致缓存和数据库数据不一致，大致分为如下两种场景。
| 场景 | 问题 |
|---|---|
| 先删除缓存，再更新数据库 | 先删除缓存值， 数据库更新失败，导致请求再次访问缓存时，发现缓存缺失，再读数据库时，从数据库中读到旧值 |
| 先更新数据库，再删除缓存 | 缓存删除失败，导致请求再次访问缓存时，发现缓存命中，并从缓存中读取到旧值 |
如何解决数据不一致的问题
无论是先操作缓存，还是先操作数据库，假如后者执行失败，我们可以发起重试，尽可能地去做「补偿」。我们可以把要更新/删除的值暂存到消息队列中，当应用没有能够成功地更新/删除数据库值时，可以从消息队列中重新读取这些值，然后再次进行删除或者更新。
这种做法引入消息队列，可能会增加更多的维护成本。如果重试超过的一定次数还是失败，需要向业务层发送报错信息。
注意：即使这两个操作执行时都没有失败，但是当有大量并发请求时，应用还是可能会读到不一致的数据。还是分以下两种情况讨论！
先更新数据库，再删除缓存
假设线程 A 删除了数据库中的值，但还没来得及删除缓存，线程 B 就开始读取数据了，那么此时，线程 B 查询缓存时，就会直接从缓存中读取到旧值。不过这种情况下，如果其他线程并发读缓存的请求不多，那么就不会有很多请求读取到旧值。并且线程 A 一般也会很快删除缓存值，这样其他线程再次读取时，就会发生缓存缺失，然后去数据库中获取最新的值，因此这种情况对业务的影响较小。
先删除缓存，再更新数据库（延迟双删）
我们先删除缓存，然后更新数据库的值，更新完数据库值以后，我们可以让线程先 sleep 一小段时间，再进行一次缓存删除操作。
这就是延迟双删，伪代码如下
redis.delKey(K)
db.update(K)
Thread.sleep(T)
redis.delKey(K)
有了sleep 的这段时间，即使有其他缓存从数据库读取到旧的值并重新放到缓存中，我们也能再次删除，保证缓存中会是新的值。至于sleep的这个时间如何确定？以实际业务执行时间为准。
总结
- 删除缓存或更新数据库失败导致的数据不一致，我们可以使用重试机制确保操作成功。
- 在删除缓存、更新数据库的这两步操作中，有其他线程的并发读导致其他线程读取到旧值，我们可以使用延迟双删方案解决。
