缓存数据和数据库数据一致性问题

前言：缓存机制是互联网搬砖人必须要掌握的基础知识之一，在使用Redis中间件时数据的幂等性问题是每个搬砖人应该掌握的。本篇文章围绕一致性问题逐步引入讲解下Redis的一致性问题。

 

首先思考下为啥要使用缓存？

存储如mysql通常支持完整的ACID特性，因为可靠性，持久性等因素，性能普遍不高，高并发的查询会给mysql带来压力，造成数据库系统的不稳定。同时也容易产生延迟。根据局部性原理，80%请求会落到20%的热点数据上，在读多写少场景，增加一层缓存非常有助提升系统吞吐量和健壮性。

 

通常的开发模式中，都会使用mysql作为存储，而redis作为缓存，加速和保护mysql。但是，当mysql数据更新之后，redis怎么保持同步呢。强一致性同步成本太高，如果追求强一致，那么没必要用缓存了，直接用mysql即可。通常考虑的，都是最终一致性。

 

本篇列举三种方案解决一致性问题分析。在面试过程中，面试官可能会一一列举出来锤炼我们。所以我们必须都要去了解，然后拿出我胡汉三怕过谁的气势征服他们。

以下是三种方案：

1. 先更新数据库，再更新缓存
2. 先删除缓存，再更新数据库
3. 先更新数据库，再删除缓存

方案一：先更新数据库，再更新缓存
1、A更新数据库数据为a
2、B更新数据库数据为b
3、B更新缓存数据为b
4、A更新缓存数据为a
问题：这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。会导致了脏数据，本方案可靠性不高。

 

方案二：先删除缓存，再更新数据库
1、A删除缓存
2、B查询缓存未查到
3、B查询数据库为b，并更新缓存
4、A修改数据库为a
问题：最终，数据库数据为a，而缓存数据为b
有个延时策略可以解决这个方法，就是在更新数据库之后，定时任务(例如1s后)执行删除缓存，把这期间保存的缓存数据删除掉，这个1s时间需要自己估项目的读数据业务逻辑的耗时。

针对删除失败，需要考虑到重试机制，详细见方案三。

 

方案三：先更新数据库，再删除缓存
1、缓存失效
2、A未查询到缓存，查询数据库
3、B更新数据库
4、B删除缓存
5、A更新缓存

问题：如果删除缓存出现异常呢？

我们可以基于通过使用 Canal 组件来获读取最新的 Binlog 日志数据添加到队列中来实现一套方案。

找了一张不错的图如下：