1、redis和mysql
一般都知道mysql是数据库的,可redis也是数据库,两者区别是
mysql:关系型数据库,️将数据存放在硬盘中,存取速度较慢 ️ 永久存放
redis:非关系型数据库(缓存数据库),️将数据放在缓存中,存取速度较快 ️ 保持时间有限 ️ 如果需要性能反应特别迅速的话,需要存在redis里
mysql | redis | |
类型 | 关系型数据库 | 非关系型数据库(缓存数据库) |
速度& 存放 | 将数据存放在硬盘中,存取速度较慢 | 将数据放在缓存中,存取速度较快 |
存放时间 | 永久存放 | 保持时间有限 |
使用场景(举例) | MySQL偏向于存数据,可 存基本数据 |
Redis偏向于快速取数据,可放置 热门的数据放Redis |
费用 | 费用较高 |
2、使用redis之后的后果
常见的缓存问题有三个。
1、缓存与数据库双写不一致。
缓存和数据库双写不一致的原因
我们先来看看缓存和数据库一致性定义:缓存中有数据,且和数据库数据一致;
缓存中无数据,数据库数据是最新的。
那么不符合这两种情况就属于缓存和数据库不一致的问题了。当客户端发送一个数据修改的请求,我们不仅要修改数据库,还要一并操作(修改/删除)缓存。对数据库和缓存的操作又存在一个顺序的问题:到底是先操作数据库还是先操作缓存。
下面我们以客户端向 MySQL 中删改数据为例来分析数据不一致的情况。
先不考虑并发问题,正常情况下,无论谁先谁后,都可以让两者保持一致,但现在我们需要重点考虑异常情况。
此时应用既要修改数据库也要修改缓存(删除和修改的影响是类似的,方便起见,下面只描述修改操作)的数据。
这里有两种场景我们分别来看下:
先修改缓存,再修改数据库
先修改数据库,再修改缓存
我们假设应用先修改缓存,再修改数据库。如果缓存修改成功,但是数据库操作失败,那么,应用再访问数据时,缓存中的值是正确的,但是一旦缓存中「数据失效」或者「缓存宕机」,然后,应用再访问数据库,此时数据库中的值为旧值,应用就访问到旧值了。如果我们先更新数据库,再更新缓存中的值,是不是就可以解决这个问题呢?我们继续分析。
如果应用先完成了数据库的更新,但是,在更新缓存时失败了。那么,数据库中的值是新值,而缓存中的是旧值,这肯定是不一致的。
这个时候,如果有其他的并发请求来访问数据,按照正常的访问流程,就会先在缓存中查询,此时,就会读到旧值了。
好了,到这里,我们可以看到,在操作数据库和更新缓存值的过程中,无论这两个操作的执行顺序谁先谁后,只要「第二步的操作」失败了,就会导致客户端读取到旧值。
我们继续分析,除了「第二步操作失败」的问题,还有什么场景会影响数据一致性:并发问题。
原文链接:https://blog.csdn.net/D812359/article/details/121645548
2、缓存雪崩
3、缓存穿透
3、怎么解决数据不一致的问题
介绍一种方法:「基于消息队列的重试机制」。参考:https://blog.csdn.net/D812359/article/details/121645548
文章评论