缓存和数据库一致性问题

发布时间：2022-09-30 12:46:21 所属栏目：MySql教程来源：

导读：　　文章目录

　　如何确保缓存和数据库的一致性？是先更新缓存还是先更新数据库？这是我曾经面试遇到的一个问题

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

　　在日常开发中，为了提高数据响应速度，会将一些高频

　　文章目录

　　如何确保缓存和数据库的一致性？是先更新缓存还是先更新数据库？这是我曾经面试遇到的一个问题

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

　　在日常开发中，为了提高数据响应速度，会将一些高频数据保存在缓存中，这样就不用每次请求都去查询数据库，可以提高服务接口的响应速度。缓存工具有很多，目前最常使用的应该就是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，其中A写数据，B读数据，具体流程如下：

　　这样下来发现数据库和缓存中的数据不一致了，所以，在Cache-Aside中是先更新数据库，再删除缓存

　　2.1.3 延迟双删

　　其实无论是先更新数据库再删除缓存，还是先删除缓存再更新数据库，在并发环境下都有可能存在问题：

　　假设有A、B两个并发请求：

　　当然前面已经分析过了，尽量先操作数据库再操作缓存，但是即使这样也还是有可能存在问题，解决问题的办法就是延迟双删。

　　延迟双删是这样：先执行缓存清除操作，再执行数据库更新操作，延迟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主从同步报错故障	填坑利器？Redis如何补
mysql如何给列添注释	在mysql中有没有嵌套查