问题:当我们的数据库中的数据更新了,但是我们缓存中的数据也要进行相应的更新,这个时候我们应该怎样做?
通常都是使用双写方案来实现的。
- 先更新数据库,再更新缓存
- 先删除缓存,再更新数据库
- 先更新数据库,再删除缓存
为什么没有先更新缓存,再更新数据库?
1、先更新数据库,再更新缓存。
我们可以想象一下,当我们有两个线程进行操作的时候,假设我们想要线程B中的数据。
- 线程A先更新了数据库中的数据,
- 线程B更新了数据库的数据。
- 线程B更新了缓存,
- 线程A更新了缓存。
这样发现问题了没?
我们最后的数据是脏数据,也就是不是我们想要的数据,我们想要的是线程B中的数据。这就不合适了。
还有原因:在写多读少的情况下,我们拼命的更新数据库中的数据,导致缓存也是在更新,但是我们读的情况比较少,这样就会出现浪费性能。
2、删除缓存,在更新数据库
该方案会导致不一致的原因是。同时有一个请求A进行更新操作,另一个请求B进行查询操作。那么会出现如下情形:
- 请求A进行写操作,删除缓存
- 请求B查询发现缓存不存在
- 请求B去数据库查询得到旧值
- 请求B将旧值写入缓存
- 请求A将新值写入数据库
上述情况就会导致不一致的情形出现。而且,如果不采用给缓存设置过期时间策略,该数据永远都是脏数据。那么,如何解决呢?
采用延时双删策略。伪代码如下:
public void doubleDelay(String key, Object data) {
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);//1s过后删除数据,就会只有1s的脏数据
redis.delKey(key);
}
但是在读写分离的数据库中,刚写的数据更新到了主数据库,但是还没完成主从复制,这个时候就会有问题,比如:
- 线程A更新数据库,然后删除缓存。
- 线程B查看缓存没有,去从数据库中查找数据,但是这个时候数据库中的数据还没发生主从复制,数据是脏数据。
- 线程B更新缓存,
- 线程A的主从复制完成,数据库中的数据是A更新的数据。
这种也是可以使用双删延时来进行的,只是在原来的基础上进行增加一些主从复制的时间。
这样的话吞吐量就下降了,我们是不是可以开一个线程去延迟删除(第二次删除的时候),如果第二次删除失败了呢?
3、先更新数据库,再删缓存
- 失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。
- 命中:应用程序从cache中取数据,取到后返回。
- 更新:先把数据存到数据库中,成功后,再让缓存失效。
一个请求A做查询操作,一个请求B做更新操作,那么会有如下情形产生:
- 缓存刚好失效
- 请求A查询数据库,得一个旧值
- 请求B将新值写入数据库
- 请求B删除缓存
- 请求A将查到的旧值写入缓存
但是这个发生的概率一般比较低,我们还是可以使用其他手段来防御的。比如你删除缓存的时候我们可以使用异步删除。那是不是就没有问题了。
有的,这也是缓存更新策略(2)和缓存更新策略(3)都存在的一个问题,如果删缓存失败了怎么办,那不是会有不一致的情况出现么。比如一个写数据请求,然后写入数据库了,删缓存失败了,这会就出现不一致的情况了。这也是缓存更新策略(2)里留下的最后一个疑问。
我们通常有两种方法
方案1:
- 更新数据库数据;
- 缓存因为种种问题删除失败
- 将需要删除的key发送至消息队列
- 自己消费消息,获得需要删除的key
- 继续重试删除操作,直到成功
然而,该方案有一个缺点,对业务线代码造成大量的侵入。于是有了方案二,在方案二中,启动一个订阅程序去订阅数据库的binlog,获得需要操作的数据。在应用程序中,另起一段程序,获得这个订阅程序传来的信息,进行删除缓存操作
方案二:
- 更新数据库数据
- 数据库会将操作信息写入binlog日志当中
- 订阅程序提取出所需要的数据以及key
- 另起一段非业务代码,获得该信息
- 尝试删除缓存操作,发现删除失败
- 将这些信息发送至消息队列
- 重新从消息队列中获得该数据,重试操作。
上述的订阅binlog程序在mysql中有现成的中间件叫canal,可以完成订阅binlog日志的功能