首先，我们先来看看有哪几种一致性的情况呢？
一、一致性
1、强一致性
如果你的项目对缓存的要求是强一致性的，那么请不要使用缓存。这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。
2、弱一致性
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。
3、最终一致性
最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。一般情况下，高可用只确保最终一致性，不确保强一致性。
强一致性，读请求和写请求会串行化，串到一个内存队列里去，这样会大大增加系统的处理效率，吞吐量也会大大降低。
二、redis缓存和mysql数据库数据一致性解决
这张图，大多数人的很多业务操作都是根据这个图来做缓存的。但是一旦设计到双写或者
数据库和缓存更新等操作，就很容易出现数据一致性的问题。无论是先写数据库，在删除缓存，还是先删除缓存，在写入数据库，都会出现数据一致性的问题。列举两个小例子。
1、 先删除了redis缓存，但是因为其他什么原因还没来得及写入数据库，另外一个线程就来读取，发现缓存为空，则去数据库读取到之前的数据并写入缓存，此时缓存中为脏数据。
2、 如果先写入了数据库，但是在缓存被删除前，写入数据库的线程因为其他原因被中断了，没有删除掉缓存，就也会出现数据不一致的情况。
总的来说，写和读在多数情况下都是并发的，不能绝对保证先后顺序，就会很容易出现缓存和数据库数据不一致的情况，还怎么解决呢？
1、方案一：采用延时双删策略
基本思路： 在写库前后都进行删除缓存操作，并且设置合理的超时时间
基本步骤： 先删除缓存–再写数据库—休眠一段时间—再次删除缓存
注：休眠的时间是根据自己的项目的读数据业务逻辑的耗时来确定的。这样做主要是为了保证在写请求之前确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
该方案的弊端： 集合双删策略+缓存超时策略设置，这样最差的结果就是在超时时间内数据存在不一致，又增加了写请求的耗时。
2、方案二：一步更新缓存（基于订阅binlog的同步机制）
基本思路： mysql binlog增强订阅消费+消息队列+增量数据更新到redis—读redis：热数据基本上都在redis—写mysql：增删改都是操作mysql—更新redis数据：mysql的数据操作binlog，来更新redis
我们再来看看详细的过程
1、redis更新
1）、数据操作主要分为两大块：
一个是全量，将全部数据写去redis；另一个就是增量（update、insert、delete），实时更新。
2）、读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。
这样一旦mysql中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至redis，redis再根据binlog中的记录，对redis进行更新。
其实这种机制，很类似mysql的主从备份机制，因为mysql的主备也是通过binlog来实现的数据一致性。
这里可以结合使用canal(阿里的一款开源框架)，通过该框架可以对mysql的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得redis的数据更新达到了相同的效果。
当然，这里的消息推送工具你也可以采用别的第三方：kafka、rabbitmq等来实现推送更新redis。
欢迎小伙伴们留言讨论！
以上就是面试官常问：如何保证redis缓存和数据库的数据一致性的详细内容，更多关于redis缓存和数据库数据一致的资料请关注服务器之家其它相关文章！
原文链接：https://blog.csdn.net/weixin_45827693/article/details/118852234