Redis缓存和数据库一致性方案

Redis缓存和数据库一致性方案

如果将Redis运用到生产中，那么Redis肯定会保存一部分数据库中的数据来缓解数据库的压力，如果请求只读那么只需要命中Redis中的数据就返回，没有命中就从数据库中读取后写入到Redis中，这样的运用场景十分普遍，但如果是写操作为了保证Redis缓存和数据库一致性第一反应是不是需要更新缓存和数据库，但这样做能保证一致性吗？如果不能保证有什么解决办法呢？

对于同时更新缓存和数据库无非是两种方案

• 先更新缓存、再更新数据库。

• 先更新数据库、后更新缓存。

对于这两种方案在第一步成功，第二步失败的时候就可能造成缓存和数据库的数据不一致，下面按照异常场景分析。

更新缓存一致性分析

先更新缓存后更新数据库

当缓存更新成功数据库更新失败，那么缓存中的数据是最新值，数据库中的值是旧值，对于普通读请求其实短时间并没有影响，因为请求会命中缓存中的数据，但如果出现内存淘汰等情况，那么后续请求将无法命中缓存，需要从数据库中读取但数据库中的值是旧值，这将影响业务正常流转。

先更新数据库后更新缓存

先更新数据库成功那么数据库中的值是新值，缓存中的值是旧值，如果请求命中缓存那么用户读取的数据就是旧数据，而用户实际已经修改，只有等缓存中的值失效后才会从数据库中读取新值，显然这对业务流转也是有影响。

并发场景下的一致性分析

除了考虑普通异常的场景外，我们还需要考虑并发场景下其实存在的问题更多，如下四个方面。

1. 先更新缓存再更新数据库，写+读并发，线程A更新缓存，线程B读请求命中缓存，返回新值，线程A再更新数据库，虽然缓存和数据库有短暂的不一致情况，但影响较小，因为读请求可以在缓存中命中。

2. 先更新数据库再更新缓存，写+读并发，线程A更新数据库，线程B读取缓存，这时线程B读取的是旧缓存的数据返回，线程A更新缓存，后续读请求命中缓存就是新值，虽然有较短的缓存不一致情况，对业务影响也是较小。

3. 先更新缓存再更新数据库，写+写并发，线程A,B更新同一个数据，线程A更新缓存，线程B更新缓存，线程B更新数据库，线程A更新数据库，这样的执行顺序也有可能造成数据不一致。

4. 先更新数据库后更新缓存，写+写并发，和第三点情况类似，执行顺序不同就会造成数据不一致的情况。

除了并发一致性问题，其实我们还可以从缓存的利用率上面思考，我们更新缓存的数据可能经过一系列的计算得出结果，而这个更新的计算结果可能直到缓存淘汰都还未被使用，那这样不仅仅占用CPU资源还占用内存资源，所以这种方案并不友好，我们可以使用另外一种方案如删除缓存。

删除缓存一致性分析

删除方案同样对应两种

• 先更新数据库后删除缓存。

• 先删除缓存后更新数据库。

同样在进行第二步失败后就会造成数据不一致的情况，如下

• 先更新数据库成功，后删除缓存失败，那么后续请求访问命中缓存返回的就是旧数据，只有当缓存数据淘汰后才有能加载更新后的数据。

• 先删除缓存成功，后更新数据库失败，那么请求在缓存中没有命中，就去数据库中查询这时数据库中就是旧数据，这将对业务影响巨大。

并发场景删除缓存会有什么影响呢？

并发场景下的一致性分析

假设缓存中存在值X=1，线程A需要将X改为2，线程B读取X的值（并发写写这种场景没有数据一致性问题）。

1. 先删除缓存后更新数据库，并发读写，线程A先删除值X的缓存，线程B读取X的值发现缓存中不存在从数据库中读取旧值X=1，线程B将X=1写入缓存中，线程A将X=2的值更新到数据库，这时数据库中最新值为X=2，而缓存中为X=1。

2. 先更新数据库后删除缓存，并发读写，缓存失效X值不在缓存中，线程B从数据库中读取X的旧值，线程A将X的值改为X=2，线程A删除缓存X的值，线程B写入旧值到缓存中，这时缓存和数据库才不一致。

第一点发生的机率较大，第二点发生的几率极小，需要满足这么几点

• 缓存中的X值刚好失效。

• 发生并发读写的操作。

• 线程A执行更新数据库和删除缓存操作的时间要比线程B从数据库中查询数据的时间和将值写入缓存的时间短。

所以采用更新数据库和删除缓存的方案可以尽量保证数据的一致性。

那先删除缓存后更新数据库有数据不一致的情况如何避免呢？这里就可以使用延时双删

延时双删

延时双删从字面理解就是删除两次，在更新数据库之前删除一次，更新数据库完毕后再删除一次。

因为先删除缓存后更新数据库其实就是旧的缓存被回写了，最好的办法就是等待一段时间后再删除一次。

如何保证缓存操作和数据库操作都成功

消息队列

无论是更新缓存还是删除缓存，在同时操作缓存和数据库时，都无法保证两者都能一次性操作成功，所以我们最好的办法就是重试，这个重试并不是立即重试，因为缓存和数据库可能因为网络或者其它原因停止服务了，立即重试成功率极低，而且重试会占用线程资源，显然不合理，所以我们需要采用异步重试机制。

异步重试我们可以使用消息队列来完成，因为消息队列可以保证消息的可靠性，消息不会丢失，也可以保证正确消费，当且仅当消息消费成功后才会将消息从消息队列中删除。

订阅数据库操作日志

这个方案是近几年比较流行的方案，也就是说业务修改数据时，我们只需要更新数据库，无需修改缓存，那什么时候修改缓存呢？

以mysql为例，在数据库一条记录发生变更时就会生成一条binlog日志，我们可以订阅这种消息，拿到具体的数据，然后根据日志消息更新缓存，订阅日志目前比较流行的就是阿里开源的canal，那么我们的架构就变为如下形式。