前言
一、什么是双写一致?
双写一致就是:确保数据库和缓存中的数据是一致的!
二、为什么会有双写一致问题?
我们都知道,使用缓存的主要目的是为了提升查询的性能。
用户请求过来之后,先查缓存有没有数据,如果有则直接返回。
如果缓存没数据,再继续查数据库。
如果数据库有数据,则将查询出来的数据,放入缓存中,然后返回该数据。
如果数据库也没数据,则直接返回空。
这段逻辑正常情况下问题并不大,但是,如果数据库的某条数据刚放入缓存,又立马被更新了 ,我们又该如何更新缓存呢??
三、常见方案
先删缓存,再写数据库
先写数据库,再删缓存
1.先删缓存,再写数据库
在用户的写操作中,先执行删除缓存操作,再去写数据库。
2.先写数据库,再删缓存
在用户的写操作中,先写数据库,再去执行删除缓存操作。
四、解决方案
为了解决双写不一致问题,我们可以采取以下几种策略:
1.延迟双删保证数据的最终一致性
延迟双删是一种比较常用的解决方案。它的基本思路是:先删除缓存,然后更新数据库,最后再设置一个短暂的延时,等这个延时过去之后再删除一次缓存。这样可以确保在更新数据库和删除缓存之间的时间窗口内,即使有新的请求来查询数据,也会因为缓存中没有数据而去数据库中查询,从而保证了数据的一致性。
为什么要删除两次缓存?
在前面的步骤中,可能会存在脏数据,所以会进行第二次删除缓存,降低脏数据的出现
为什么要延迟删除?
一般来说,数据库是主从模式,他是读写分离的,我们需要延时一会,让主节点把数据同步到从节点,但是延时的时间不好控制,仍然有可能出现脏数据,所以延时双删极大的控制了脏数据的风险,但也只是一部分,也有脏数据的风险,没法保证强一致性。
2.异步通知保证数据的最终一致性
3.使用分布式锁
在某些场景下,我们可以使用分布式锁来保证在更新缓存和数据库时的一致性。具体做法是:在更新缓存和数据库之前先获取分布式锁,如果获取成功则进行更新操作,否则等待一段时间后重试。这样可以确保在同一时间只有一个操作在进行更新,从而避免了双写不一致的问题。但是,使用分布式锁也会带来一些额外的开销和复杂性,需要谨慎使用。
互斥锁
直接加互斥锁能保障数据的强一致性,但是性能较低。此时我们就需要优化一下互斥锁。因为存入缓存的数据,一般都是读多写少。为此我们引入两个单独的锁,分别叫共享锁和排他锁。
共享锁/读锁
共享锁,又叫读锁(readLock),加锁之后,其他线程可以共享读操作。
排他锁/独占锁
排他锁,又叫独占锁(writeLock),加锁之后,阻塞其他线程读和写操作。
五、面试回答模板
redis为缓存,mysql的数据如何与redis进行同步呢?
这个要看业务需求,如果要求数据的强一致性,那么一般使用读写锁来实现。读写锁是一种分布式锁机制,里面包括两种锁,一个叫共享锁,在读的时候添加共享锁,可以保证读读不互斥,读写互斥。一个叫排他锁,在写的时候添加排他锁,可以保证读写都互斥,避免脏数据的风险。
如果不要求数据的强一致性,那么就可以用基于MQ或者canal中间件的异步通知,来实现redis和mysql的双写一致性。
你的项目中用到了redis,那你mysql的数据如何与redis进行同步呢?
——————————————强一致性策略——————————————————
以我最近做的这个项目为例,里面有xxxx(根据自己的简历上写)的功能,需要让数据库与redis高度保持一致,因为要求时效性比较高,我们当时采用的读写锁保证的强一致性。
读写锁是一种分布式锁机制,里面包括两种锁,一个叫共享锁,在读的时候添加共享锁,可以保证读读不互斥,读写互斥。一个叫排他锁,在写的时候添加排他锁,可以保证读写都互斥,避免脏数据的风险。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。
面试官:那这个排他锁是如何保证读写、读读互斥的呢?
候选人:其实排他锁底层使用也是setnx,保证了同时只能有一个线程操作锁住的方法
面试官:你听说过延时双删吗?为什么不用它呢?
候选人:延迟双删,如果是写操作,我们先把缓存中的数据删除,然后更新数据库,最后再延时删除缓存中的数据,其中这个延时多久不太好确定,在延时的过程中可能会出现脏数据,并不能保证强一致性,所以没有采用它。
——————————————非强一致性策略——————————————————
面试官:redis做为缓存,mysql的数据如何与redis进行同步呢?(双写一致性)
候选人:嗯!就说我最近做的这个项目,里面有xxxx(根据自己的简历上写)的功能,数据同步可以有一定的延时(符合大部分业务)
我们当时采用的阿里的canal组件实现数据同步:不需要更改业务代码,部署一个canal服务。canal服务把自己伪装成mysql的一个从节点,当mysql数据更新以后,canal会读取binlog数据,然后在通过canal的客户端获取到数据,更新缓存即可。