Redis与数据库缓存一致性问题

一、Redis 数据一致性问题产生的原因

对 Redis和数据库的操作有 2 种方案：
1、先操作（删除） Redis，再操作数据库
2、先操作数据库，再操作（删除） Redis
上述二种方案，都希望数据操作要么都成功，要么都失败，也就是最好是一个原子操作，我们不希望看到一个失败，一个成功的结果，因为这样就产生了数据不一致的问题。
举例说明：
假设 Redis 里缓存了一个热点商品数据，有个 key 为 1 的商品名称为“衣服”，数据库里这个 1号的商品名称也是衣服；此时商家觉得商品名称叫衣服有点宽泛，需要精确一下，把 1 号商品的名称修改为其对应的具体名称“短袖”。
1、如果我们选择先操作 Redis，再操作数据库的方案，当操作 Redis 成功，操作数据库失败的时候，Redis 里的名称修改为“短袖”，但是数据库的名称还是“衣服”，产生了数据不一致问题。
2、如果我们选择先操作数据库，再操作 Redis 的方案，当操作数据库成功，操作 Redis 失败的时候，数据库里的名称修改为“短袖”，但是 Redis 的名称还是“衣服”，产生了数据不一致问题。

二、解决方案

因为数据库是稳定的持久化的系统，比 Redis可靠，我们一般都是以数据库的数据为准，解决这个数据一致性问题的原则就是：我们可以为 Redis 缓存数据设置一个过期的时间，当 Redis 数据过期了就去数据库查询，然后再把数据库的数据写入 Redis 缓存中，确保数据的一致性。
如果在这个过期时间范围内，数据发生了更新操作，当更新操作有一个失败，有一个成功，就会产生不一致的问题，这个过期时间设置的太短了，数据库的压力还是很大，过期时间设置的太长了，不一致性的问题就会凸显，因此我们需要基于以数据库的数据为准的原则下，解决一致性问题。

1.Redis 更新方案

使用场景：更新代价小，数据不会牵扯到多个接口，没有出现大型的数据，只是简单的更新，更新的数据直接可以获取到！

（1）先更新 Redis，再更新数据库

首先不推荐选择这种方案。因为我们的数据一致性的基本原则是以数据库的数据为准，所以先更新缓存的话，会存在缓存更新成功，数据库更新失败的情况，此时面临的问题就需要回滚掉刚才更新缓存成功的操作，那么就需要从业务代码里加入很多判断逻辑来处理这种异常，需要考虑数据变化是 insert,update，delete 等，根据不同的场景执行不同的回滚方案，这种回滚操作比较麻烦，对我们业务代码的倾入性也比较大，所以不推荐选择这种方案。当然，如果业务层面可以接受这种数据的不一致性，异常情况就不需要考虑，选择这种方案也是可以的。

(2) 先更新数据库，再更新 Redis

先更新数据库，再更新 Redis 的方案，由于把数据库操作放到了前面，如果数据库操作失败，那么客户端再发起一次就可以了。如果数据库操作成功，Redis 操作失败，此时由于数据库的数据已经设置成功，我们的重点就是讨论如何把 Redis的数据操作成功即可。从客户端层面来看，他提交的数据已经在我们系统里存在了，此时的问题就是我们系统内部如何解决的问题。对于 Redis 操作失败，我们可选的方案有以下几个，根据业务要求的数据一致性级别，进行权衡选择即可。
1、如果数据一致性要求不是很高，不做任何操作，等着Redis里的缓存数据过期后，自动从数据库同步最新的数据，此时最严重的数据不一致性周期就是在缓存过期的一段时间（考虑一下这个过期时间的范围）；如果在这个时间段内，又有新的更新请求，也许这次就更新缓存成功了。
2、如果数据一致性要求比较高，那么 Redis 操作失败后，我们把这个操作记录下来，异步处理，用 Redis 的数据去和数据库比对，如果不一致，再次更新缓存确保缓存数据与数据库数据一致。

2.选择 Redis 删除方案（主流）

应用场景：拿到数据更新到 Redis 需要经过很多表的关联查询，或者多个接口的调用查询，经过大量计算才能得到数据的话，就不要使用更新 Redis 的方案了，因为面对这种复杂的更新流程，可以直接删掉方便。

（1）先更新数据库，再删除 Redis

我们如果更新数据库成功，删除 Redis 失败，那么 Redis 里存放的就是一个旧值，也就是删除缓存失败导致缓存和数据库的数据不一致了。对于删除 Redis 失败的异常情况来进行分析，我们一般有如下的方案：
1、我们可以重试删除，比如：我们可以把删除动作发送到消息队列 MQ，MQ的消费者再去删除这个key，一致尝试删除操作，确保缓存删除成功，这个方案缺陷就是删除缓存的地方，通过代码实现对业务逻辑产生了入侵。
2、另外一种方案，就是完全异步的方案，对业务逻辑没有入侵，通过监听 binlog 的变化来删除缓存。我们更新数据库会产生 binlog，我们可以用一个服务监听数据库 binlog 的变化，异步去删除缓存，阿里开源的 canal 就是可以监听 binlog 的工具，只要数据发生变化就可以删除 Redis 的数据。

（2）先删除 Redis，再更新数据库

并发下可能产生数据一致性问题。
举例：

上面的图表示，Thread-1 是个更新流程，Thread-2 是个查询流程，cpu 执行顺序是：Thread-1 删除缓存成功，此时 Thread-2 获取到 CPU 执行查询缓存没有数据，然后查询数据库把数据库的值写入缓存，因为此时 Thread-1 更新数据库还没有执行，所以缓存里的值是一个旧值（old），最后 CPU 执行 Thread-1 更新数据库成功的代码，那么此时数据库的值是新增（new），这样就产生了数据不一致行的问题。
解决上述问题的两种方案：
（1）加锁，使线程顺序执行：如果一个服务部署到了多个机器，就变成了分布式锁，或者是分布式队列按顺序去操作数据库或者 Redis，带来的副作用就是：数据库本来是并发的，现在变成串行的了，加锁或者排队执行的方案降低了系统性能，所以这个方案看起来不太可行。
（2）采用双删：先删除缓存，再更新数据库，当更新数据后休眠一段时间再删除一次缓存。
伪代码：

redes.del(key);
db.update(data);
Thread.sleep(2000);
redes.del(key);