本篇内容主要讲解“实现Redis缓存和数据库的数据一致性的方法”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“实现Redis缓存和数据库的数据一致性的方法”吧!
一、一致性
1、强一致性
2、弱一致性
3、最终一致性
二、redis缓存和mysql数据库数据一致性解决
1、方案一：采用延时双删策略
2、方案二：一步更新缓存（基于订阅Binlog的同步机制）
首先，我们先来看看有哪几种一致性的情况呢？
如果你的项目对缓存的要求是强一致性的，那么请不要使用缓存。这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。
3、最终一致性
最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。一般情况下，高可用只确保最终一致性，不确保强一致性。
强一致性，读请求和写请求会串行化，串到一个内存队列里去，这样会大大增加系统的处理效率，吞吐量也会大大降低。
这张图，大多数人的很多业务操作都是根据这个图来做缓存的。但是一旦设计到双写或者
数据库和缓存更新等操作，就很容易出现数据一致性的问题。无论是先写数据库，在删除缓存，还是先删除缓存，在写入数据库，都会出现数据一致性的问题。列举两个小例子。
1、 先删除了redis缓存，但是因为其他什么原因还没来得及写入数据库，另外一个线程就来读取，发现缓存为空，则去数据库读取到之前的数据并写入缓存，此时缓存中为脏数据。
2、 如果先写入了数据库，但是在缓存被删除前，写入数据库的线程因为其他原因被中断了，没有删除掉缓存，就也会出现数据不一致的情况。
总的来说，写和读在多数情况下都是并发的，不能绝对保证先后顺序，就会很容易出现缓存和数据库数据不一致的情况，还怎么解决呢？
基本思路： 在写库前后都进行删除缓存操作，并且设置合理的超时时间
基本步骤： 先删除缓存–再写数据库—休眠一段时间—再次删除缓存
注：休眠的时间是根据自己的项目的读数据业务逻辑的耗时来确定的。这样做主要是为了保证在写请求之前确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
该方案的弊端： 集合双删策略+缓存超时策略设置，这样最差的结果就是在超时时间内数据存在不一致，又增加了写请求的耗时。
基本思路： mysql Binlog增强订阅消费+消息队列+增量数据更新到redis—读redis：热数据基本上都在redis—写mysql：增删改都是操作mysql—更新redis数据：mysql的数据操作Binlog，来更新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缓存和数据库的数据一致性的方法”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
