1、redis和mysql

一般都知道mysql是数据库的，可redis也是数据库，两者区别是

mysql：关系型数据库，1⃣️将数据存放在硬盘中，存取速度较慢 2⃣️ 永久存放

redis：非关系型数据库(缓存数据库)，1⃣️将数据放在缓存中，存取速度较快 2⃣️ 保持时间有限 3⃣️ 如果需要性能反应特别迅速的话，需要存在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

转载：Redis和数据库数据不一致的问题_啊勇的博客的博客-CSDN博客_如何解决数据库和redis数据不一致问题针对读多写少的高并发场景，我们可以使用缓存来提升查询速度。• 如果数据在Redis存在，应用就可以直接从Redis拿到数据，不用访问数据库。• 如果Redis里面没有，先到数据库查询，然后写入到Redis，再返回给应用。问题一：一旦被缓存的数据发生变化的时候，我们既要操作数据库的数据，也要操作Redis的数据，所以问题来了。现在我们有两种选择：• 先操作Redis的数据再操作数据库的数据• 先操作数据库的数据再操作Redis的数据只要有一方失败就会导致数据不一致这种情况需要更具https://blog.csdn.net/ayonglink/article/details/121756627