https://blog.csdn.net/zxd1435513775/article/details/123840314
文章目录
如何确保缓存和数据库的一致性?是先更新缓存还是先更新数据库?这是我曾经面试遇到的一个问题
1. 缓存和数据库一致性问题
在日常开发中,为了提高数据响应速度,会将一些高频数据保存在缓存中,这样就不用每次请求都去查询数据库,可以提高服务接口的响应速度。缓存工具有很多,目前最常使用的应该就是 Redis
。
对于缓存的使用,并不是所有场景都要使用缓存,可以根据业务对数据要求的实时性,选择性的使用缓存,例如:
- 订单和支付数据,这两类数据对实时性和精确性要求很高,所以一般不需要添加缓存,直接操作数据库
- 用户相关数据,这些数据和用户相关,具有读多写少特点,所以可以使用
Redis
进行缓存 - 某些配置信息,这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以可以使用本地内存进行缓存
下面来看一下使用缓存的流程:
第一次请求数据时会去查询数据库,然后把数据存入 Redis
中,对于接下来的每次请求都会先去 Redis
中看看存不存在,如果存在就直接返回,如果不存在,就去数据库中查询,将从数据库中查询到的数据缓存到 Redis
中。
然而,当数据存入缓存之后,如果数据需要更新的话,往往会来带另外的问题:
当有数据需要更新的时候,先更新缓存还是先更新数据库?如何保证更新缓存和更新数据库这两个操作的原子性?
更新缓存的时候该怎么更新?修改还是删除?
对于上述问题,无非就四种方案:
- 先更新缓存,再更新数据库
- 先更新数据库,再更新缓存
- 先淘汰缓存,再更新数据库
- 先更新数据库,再淘汰缓存
那到底使用哪种方式呢?
2. 三个经典的缓存模式
2.1 Cache-Aside
最经典的缓存+数据库读写的模式,就是Cache Aside
。如果在项目中采用 Cache-Aside
模式,那么就可以尽可能的解决缓存与数据库数据不一致的问题,注意是尽可能的解决,并无法做到绝对解决。Cache-Aside
分为读缓存和写缓存两种情况,要分别来看。
- 读的时候,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应
- 更新的时候,先更新数据库,然后再删除缓存
2.1.1 读缓存
读缓存表示读取数据时,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。看一下流程图:
具体流程:
- 读取数据
- 查缓存中是否有需要的数据,如果命中缓存,则直接返回数据
- 如果没有命中缓存,那么就访问数据库
- 将从数据库中读取到的数据设置到缓存中
- 返回数据
这是 Cache-Aside
的读缓存流程,其实对于读缓存的流程而言,一般都没什么异议,有异议的主要是写流程
2.1.2 写缓存
写缓存表示更新数据的时候,先更新数据库,然后再删除缓存,看一下流程图:
这个写缓存的流程就比较简单,先更新数据库中的数据,然后删除旧的缓存即可,流程虽然简单,但是却引发出两个问题:
- 为什么是删除旧缓存,而不是更新旧缓存?
- 为什么不先删除旧的缓存,然后再更新数据库?
为什么是删除旧缓存而不是更新旧缓存?
- 这个原因很简单,复杂点的缓存场景,缓存不单单是数据库中直接取出来的值,而是一些复杂操作或者计算(例如大量联表操作、一些分组计算)的结果,如果不加缓存,不但无法满足高并发量,同时也会给数据库带来巨大的负担,那么对于这样的缓存,更新起来实际上并不容易,此时选择删除缓存效果会更好一些
- 对于一些写频繁的应用,如果按照更新缓存->更新数据库的模式来,比较浪费性能,因为首先写缓存很麻烦,其次每次都要写缓存,但是可能写了十次,只读了一次,读的时候读到的缓存数据是第十次的,前面九次写缓存都是无效的,对于这种情况不如采取先写数据库再删除缓存的策略
- 在多线程环境下,这样的更新策略还有可能会导致数据逻辑错误,来看下流程图:
可以看到,有两个并发的线程 A
和 B
:
- 首先
A
线程更新了数据库 - 接下来
B
线程更新了数据库 - 由于网络等原因,
B
线程先更新了缓存 A
线程更新了缓存
那么此时,缓存中保存的数据就是不正确的,而如果采用了删除缓存的方式,就不会发生这种问题了,因为缓存删除了,就要实时去数据库中查询,数据库中的数据是两个线程更新后的结果。
那为什么不先删除旧的缓存,然后再更新数据库?
这个也是考虑到并发请求,假设先删除旧的缓存,然后再更新数据库,那么就有可能出现如下这种情况:
这个操作是这样的,有两个线程,A
和 B
,其中 A
写数据,B
读数据,具体流程如下:
A
线程首先删除缓存B
线程读取缓存,发现缓存中没有数据B
线程读取数据库B
线程将从数据库中读取到的数据写入缓存A
线程更新数据库
这样下来发现数据库和缓存中的数据不一致了,所以,在 Cache-Aside
中是先更新数据库,再删除缓存
2.1.3 延迟双删
其实无论是先更新数据库再删除缓存,还是先删除缓存再更新数据库,在并发环境下都有可能存在问题:
假设有 A
、B
两个并发请求:
- 先更新数据库再删除缓存:当请求
A
更新数据库之后,还未来得及进行缓存清除,此时请求B
查询到并使用了Cache
中的旧数据 - 先删除缓存再更新数据库:当请求
A
执行清除缓存后,还未进行数据库更新,此时请求B
进行查询,查到了旧数据并写入了Cache
当然前面已经分析过了,尽量先操作数据库再操作缓存,但是即使这样也还是有可能存在问题,解决问题的办法就是延迟双删。
延迟双删是这样:先执行缓存清除操作,再执行数据库更新操作,延迟N秒之后再执行一次缓存清除操作,这样就不用担心缓存中的数据和数据库中的数据不一致。
那么这个延迟N
秒,N是
多大比较合适呢?一般来说,N
要大于一次写操作的时间,如果延迟时间小于写入缓存的时间,会导致请求A
已经延迟清除了缓存,但是此时请求B
缓存还未写入,具体是多少,需要结合自己的业务来统计这个数值了。
2.1.4 如何确保操作缓存和操作数据库的原子性
更新数据库和删除缓存毕竟不是一个原子操作,要是数据库更新完毕后,删除缓存失败了咋办?
对于这种情况,一种常见的解决方案就是使用消息中间件来实现删除的重试。MQ
一般都自带消费失败重试的机制,当要删除缓存的时候,就往 MQ
中扔一条消息,缓存服务读取该消息并尝试删除缓存,删除失败了就会自动重试。
2.2 Read-Through/Write-Through
2.2.1 Read-Through
乍一看,感觉和Cache-Aside
一样,没啥区别,单看流程是不太容易看到区别。
Read-Through
是一种类似于Cache-Aside
的缓存方法,区别在于,在Cache-Aside
中,由应用程序决定去读取缓存还是读取数据库,这样就会导致应用程序中出现了很多业务无关的代码;而在 Read-Through
中,相当于多出来了一个中间层 Cache Middleware
,由它去读取缓存或者数据库,应用层的代码得到了简化,回忆下 Spring Cache
中的 @Cacheable
注解,感觉像不像 Read-Through
?
画一个简单的流程图大家来看下:
可以看到,和 Cache-Aside
相比,其实就相当于是多了一个Cache Middleware
,这样在应用程序中就只需要正常的读写数据就行了,并不用管底层的具体逻辑,相当于把缓存相关的代码从应用程序中剥离出来了,应用程序只需要专注于业务。
2.2.2 Write-Through
Write-Through
其实也是差不多,所有的操作都交给Cache Middleware
来完成,应用程序中就是一句简单的更新就行了,来看看流程:
在 Write-Through
策略中,所有的写操作都经过 Cache Middleware
,每次写入时,Cache Middleware
会将数据存储在 DB
和 Cache
中,这两个操作发生在一个事务中,因此,只有两个都写入成功,一切才会成功。
2.3 Write Behind
Write-Behind
缓存策略类似于 Write-Through
缓存,应用程序仅与 Cache Middleware
通信,Cache Middleware
会预留一个与应用程序通信的接口。
Write-Behind
与Write-Through
最大的区别在于,前者是数据首先写入缓存,一段时间后(或通过其他触发器)再将数据写入 Database
,并且这里涉及到的写入是一个异步操作。这种方式下,Cache
和 DB
数据的一致性不强,对一致性要求高的系统要谨慎使用,如果有人在数据尚未写入数据源的情况下直接从数据源获取数据,则可能导致获取过期数据,不过对于频繁写入的场景,这个其实非常适用。
将数据写入 DB
可以通过多种方式完成:
一种是收集所有写入操作,然后在某个时间点(例如,当 DB
负载较低时)对数据源进行批量写入。
另一种方法是将写入合并成更小的批次,例如每次收集五个写入操作,然后对数据源进行批量写入。
文章知识点与官方知识档案匹配,可进一步学习相关知识
MySQL入门技能树数据库组成表11523 人正在系统学习中