面试前必须要知道的Redis面试

一般我们都是采取删除缓存缓存策略的，原因如下：

1. 高并发环境下，无论是先操作数据库还是后操作数据库而言，如果加上更新缓存，那就更加容易导致数据库与缓存数据不一致问题。(删除缓存直接和简单很多)
2. 如果每次更新了数据库，都要更新缓存【这里指的是频繁更新的场景，这会耗费一定的性能】，倒不如直接删除掉。等再次读取时，缓存里没有，那我到数据库找，在数据库找到再写到缓存里边(体现懒加载)

基于这两点，对于缓存在更新时而言，都是建议执行删除操作!

3.3.2先更新数据库，再删除缓存正常的情况是这样的：

• 先操作数据库，成功;
• 再删除缓存，也成功;

如果原子性被破坏了：

• 第一步成功(操作数据库)，第二步失败(删除缓存)，会导致数据库里是新数据，而缓存里是旧数据。
• 如果第一步(操作数据库)就失败了，我们可以直接返回错误(Exception)，不会出现数据不一致。

如果在高并发的场景下，出现数据库与缓存数据不一致的概率特别低，也不是没有：

• 缓存刚好失效
• 线程A查询数据库，得一个旧值
• 线程B将新值写入数据库
• 线程B删除缓存
• 线程A将查到的旧值写入缓存

要达成上述情况，还是说一句概率特别低：

因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。

对于这种策略，其实是一种设计模式：Cache Aside Pattern

先修改数据库，再删除缓存

删除缓存失败的解决思路：

• 将需要删除的key发送到消息队列中
• 自己消费消息，获得需要删除的key
• 不断重试删除操作，直到成功

3.3.3先删除缓存，再更新数据库正常情况是这样的：

• 先删除缓存，成功;
• 再更新数据库，也成功;

如果原子性被破坏了：

• 第一步成功(删除缓存)，第二步失败(更新数据库)，数据库和缓存的数据还是一致的。
• 如果第一步(删除缓存)就失败了，我们可以直接返回错误(Exception)，数据库和缓存的数据还是一致的。

看起来是很美好，但是我们在并发场景下分析一下，就知道还是有问题的了：

• 线程A删除了缓存
• 线程B查询，发现缓存已不存在
• 线程B去数据库查询得到旧值
• 线程B将旧值写入缓存
• 线程A将新值写入数据库

所以也会导致数据库和缓存不一致的问题。

并发下解决数据库与缓存不一致的思路：

• 将删除缓存、修改数据库、读取缓存等的操作积压到队列里边，实现串行化。

将操作积压到队列中

3.4对比两种策略

我们可以发现，两种策略各自有优缺点：

• 先删除缓存，再更新数据库
  • 在高并发下表现不如意，在原子性被破坏时表现优异
• 先更新数据库，再删除缓存(Cache Aside Pattern设计模式)
  • 在高并发下表现优异，在原子性被破坏时表现不如意

3.5 其他保障数据一致的方案与资料

可以用databus或者阿里的canal监听binlog进行更新。

参考资料：

• 缓存更新的套路

https://coolshell.cn/articles/17416.html

• 如何保证缓存与数据库双写时的数据一致性?

https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/redis-consistence.md

• 分布式之数据库和缓存双写一致性方案解析

https://zhuanlan.zhihu.com/p/48334686

• Cache Aside Pattern

https://blog.csdn.net/z50l2o08e2u4aftor9a/article/details/81008933

最后

这是几道Redis常见的面试题，希望大家看完有所帮助，顺利拿到offer!

【编辑推荐】

1. 2月数据库排行榜：MySQL分数增长迅猛，Oracle下降最多
2. MySQL主从复制虽好，能完美解决数据库单点问题吗？
3. 开源数据库：PostgreSQL、MariaDB和SQLite的对比
4. 聊聊Java数据库开发的那点事儿
5. 一文揭秘单线程的Redis为什么这么快?

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!