如何保持mysql和redis中数据的一致性？

 

学习了一下redis，了解了它的出现背景和基本用法，对于不轻易改变的数据，首次可以将其从mysql中取出存到redis中，以后只要判断redis有没有这个数据，有的话直接拿来用就行了。那么，如果在redis获取这个数据以后，我到mysql中更新了数据，那么redis中的数据不就和mysql不一致了吗？怎么让redis中的数据和mysql保持实时一致呢？

 

这实际上是个“如果要做的足够精致是非常难的“问题。缓存失效被称为计算机科学里最难的两个问题之一（另外一个是起名字）。

先对本题一致性做个说明。这里的不一致是指：假如一个数据访问者同时读取Redis和DB，他能在一段时间里发现二者不一样。

不错，如果一份数据放在DB，然后copy到Redis，然后改DB，那么Redis是不会自己魔幻般同步变更的。必须有某种机制告诉Redis该变了。这些机制包括（但不仅仅限于）：

1. Redis里的数据不立刻更新，等redis里数据自然过期。然后去DB里取，顺带重新set redis。这种用法被称作“Cache Aside”。好处是代码比较简单，坏处是会有一段时间DB和Redis里的数据不一致。这个不一致的时间取决于redis里数据设定的有效期，比如10min。但如果Redis里数据没设置有效期，这招就不灵了。

2. 更新DB时总是不直接触碰DB，而是通过代码。而代码做的显式更新DB，然后马上del掉redis里的数据。在下次取数据时，模式就恢复到了上一条说的方式。这也算是一种Cache Aside的变体。这要做的好处是，数据的一致性会比较好，一般正常情况下，数据不一致的时间会在1s以下，对于绝大部分的场景是足够了。但是有极少几率，由于更新时序，下Redis数据会和DB不一致（这个有文章解释，这里不展开）。

Cache Aside，就是“Cache”在DB访问的主流程上帮个忙

1和2的做法常规上被称为“Cache“。而且因为1有更新不及时的问题，2有极端情况下数据会不一致的问题，所以常规Cache代码会把1+2组合起来，要求Redis里的数据必须有过期时间，并且不能太长，这样即便是不一致也能混过去。同时如果是主动对数据进行更新，Cache的数据更新也会比较及时。

并且2并不一定总是行得通。比如OLTP的服务在前面是Cache+DB的模式，而数据是由后台管理系统来更新的，总是不会触碰OLTP服务，更不会动Cache。这时将Redis看作是存储也算是一种方案。就是：

3. Redis里的数据总是不过期，但是有个背景更新任务（“定时执行的代码” 或者 “被队列驱动的代码）读取db，把最新的数据塞给Redis。这种做法将Redis看作是“存储”。访问者不知道背后的实际数据源，只知道Redis是唯一可以取的数据的地方。当实际数据源更新时，背景更新任务来将数据更新到Redis。这时还是会存在Redis和实际数据源不一致的问题。如果是定时任务，最长的不一致时长就是更新任务的执行间隔；如果是用类似于队列的方式来更新，那么不一致时间取决于队列产生和消费的延迟。常用的队列（或等价物）有Redis（怎么还是Redis），Kafka，AMQ，RMQ，binglog，log文件，阿里的canal等。

Cache当作“存储”来用，访问者只看得到Cache

这种做法还有一种变体Write Through，写入时直接写DB，DB把数据更新Cache，而读取时读Cache。

Write Through + Cache当存储

以上方式无论如何都会有一段时间Redis和DB会不一致。实践上，这个不一致时间短则几十ms，长可以到几十分钟。这种程度的一致性对于很多业务场景都已经足够了。很多时候，用户无法区分自己读取的是Redis还是DB，只能读取到其中的一个。这时数据看起来直觉上是没问题的就可以接受了。只要不出现，用户先看见了数据是A，然后看到数据是B，之后一刷新，又看到A的尴尬场景就行了。（这也可以部份解释为啥用经常使用共享式的Cache而不是本地Cache方案）。

但对于有些业务，比如协作文档编辑，电商秒杀的扣库存，银行转账等，以上的做法就不够用了。解决办法也有两大类。第一种是不要用Redis，只用DB。或者更直接点说是“只要一个单点的数据源”。这样肯定就没有一致性问题，代价就是CAP中因为CP被满足，因此A被牺牲掉。这就是为啥银行一系统升级就要停服务的原因。

当然实际上也有CAP兼顾，但是C要的强一点，A就得弱一点，但不至于完全牺牲掉的做法。这里不展开。

另外一种保证一致性的做法就是用某种分布式协议一致性来做，大致可以归结到

1. SAGA或者TCC - 这两种需要业务代码的大量配合。通过业务代码来补偿一致性。
2. 2PC, 3PC - 现实当中有XA协议。比如Ehcache是支持XA协议的。但是性能表现不佳，运维也麻烦，我比较少见到实际这么干的。
3. 基于Paxos或者Raft的分布式锁，然后对Redis和DB进行双写，但是除非客户端和服务器么次都去访问分布式锁，也会有一点点不一致的问题。这实际上相当于将多个地方的一致性控制交给了分布式锁的集中维护。

这些做法实施复杂度和运维复杂度太高，以至于对于像Redis + DB这种场景基本上没人这么干。本质上大家用Redis一般也就是想做个Cache而已。这些方案通常被用到比如多数据中心数据一致性维护的系统中。

综上，除了单点DB存储之外的方案，其一致性面临的窘境是

• 要么，接受“最终一致”，但到底多久之后一致，不一致时表现怎么样，有很多种做法。分布式一致性有各种各样的模型，比如线性一致性、顺序一致性等。他们都是在“不一致”和“强一致”之间提供某种折衷。这些折衷大量应用于我们常见的诸多业务之中、如社交、IM、电商不触及钱的地方等
• 要么，要求必须强一致。那么在分布式条件下就要牺牲A。比如访问一个Cache，Cache知道自己的数据不是最新的，就要和DB去Sync，Sync的过程中DB的数据还不能改。期间访问者要不收到一个错误“数据不同步，不能访问”，要不就卡在那里等着同步完成。个人以为，这还不如干脆就不要Cache，在维护强一致的同时，用其他方式来优化访问性能。

最最后提醒下，本文有很多不严谨的地方，包括对Cache的形式总结其实只有典型的几种，实际可能的要多得多；再比如对一致性的介绍也非常粗浅，原因是为了让初学者有一点点概念，能看得进去（就这样，已经很长了，评论区里也有人表示接受不了）。

对于分布式和其一致性的完整知识的学习需要耗费大量的精力，Good Luck & Best Wishes。

 

写入数据库成功，即让缓存失效，下一次读取时再缓存。这是缓存的实时策略。当然，并不适用于所有的场景。

缓存一般是直接将数据放到离计算最近的地方（目前大部分放在内存中），解决 CPU 和 I/O 的速度不匹配的问题，用来加快计算处理速度，通常会对热点数据进行缓存，保证较高的命中率。在互联网的架构设计中，数据库及缓存一般相互配合使用来满足不同的场景需求，比如在大流量的请求中会使用缓存来加速。

Redis 在互联网行业中使用最为广泛。Redis 在很多时候也被称为“内存数据库”，它集合了缓存和数据库的优势，但并非开启持久化和主备同步机制就可以高枕无忧。从架构设计的角度思考：缓存就是缓存，缓存数据会随时丢失，缓存存在的目的是拦截到数据库的请求，相比数据的可靠性、一致性，还是吞吐量、稳定性优先。

缓存有三大矛盾：

1. 缓存实时性和一致性问题：当有了写入后咋办？
2. 缓存的穿透问题：当没有读到咋办？
3. 缓存对数据库高并发访问：都来访问数据库咋办？

第一个也就是本问题。而解决这三大矛盾的刷新策略包括：

1. 实时策略——用户体验好，是默认应该使用的策略；
2. 异步策略——适用于并发量大，但是数据没有那么关键的情况，好处是实时性好；
3. 定时策略——并发量实在太大，数据量也大的情况，异步都难以满足的场景；

实时策略是最常用的策略，也是保持实时性最好的策略：

• 读取的过程，应用程序先从 cache 取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。如果命中，应用程序从 cache 中取数据，取到后返回。
• 写入的过程，把数据存到数据库中，成功后，再让缓存失效，失效后下次读取的时候，会被写入缓存。

从用户体验的角度，应该数据库有了写入，就马上废弃缓存，触发一次数据库的读取，从而更新缓存。

然而，这和第三个问题（高并发）就矛盾了——如果所有的都实时从数据库里面读取，高并发场景下，数据库往往受不了。

 

异质数据系统（heterogeneous data system）之间的同步其实是分布式系统设计领域一个非常经典的场景。一种方案是双写（dual writes），即发生数据变更时应用程序代码同时写入数据库和Redis。比如先写入数据库，再更新Redis。这种方案的缺陷主要有两个：

1. 多次写入构成的race condition：比如系统状态中有个状态x，初始值是0。现在客户端A写入x=1，客户端B写入x=2。假设都是先写数据库，然后更新Redis。那么如果B的双写在A的双写之间完成，那么就可能出现这样的情况：数据库中x=2(因为是B最后更新)；Redis中x=1（因为是A最后更新）——故造成不一致

2. 部分失败（partial failure）：假设只有一个客户端A更新，先更新数据库成功，后更新Redis失败——同样造成不一致

要解决第一个问题，你需要有额外的并发检测机制。常见的方案有version vector等；解决第二个问题需要你提供分布式事务。我们熟知的有2PC方案，但是2PC性能是出了名的差。目前为止我还没有在互联网公司看到过XA或2PC的太多实际使用案例，毕竟代价太大了。

实际上目前更加流行的做法是用CDC的方式来做。CDC，即Change Data Capture，主要思想是将数据库的每次变更追加写入到一个日志中，然后让Redis按照日志中的变更顺序重演一遍更新操作，这样就能保证Redis与数据库保持同步。CDC基本的思想就是让你的权威数据源（通常是数据库）成为leader副本 ，让其他的异质系统（不仅是Redis，也可以是ES、数仓等）成为follower副本，通过基于日志（log-based）的CDC机制保证leader与follower之间的同步。好消息是目前越来越多的数据库天然地提供CDC的接口或API供外部系统调用。

 

 

需求起因

在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。

这个业务场景，主要是解决读数据从Redis缓存，一般都是按照下图的流程来进行业务操作。

读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。

不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举一个例子：

1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。

如来解决？这里给出两个解决方案，先易后难，结合业务和技术代价选择使用。

缓存和数据库一致性解决方案

1.第一种方案：采用延时双删策略

在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。

伪代码如下

public void write(String key,Object data){
 redis.delKey(key);
 db.updateData(data);
 Thread.sleep(500);
 redis.delKey(key);
 }

2.具体的步骤就是：

1）先删除缓存

2）再写数据库

3）休眠500毫秒

4）再次删除缓存

那么，这个500毫秒怎么确定的，具体该休眠多久呢？

需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

当然这种策略还要考虑redis和数据库主从同步的耗时。最后的的写数据的休眠时间：则在读数据业务逻辑的耗时基础上，加几百ms即可。比如：休眠1秒。

3.设置缓存过期时间

从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。所有的写操作以数据库为准，只要到达缓存过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。

4.该方案的弊端

结合双删策略+缓存超时设置，这样最差的情况就是在超时时间内数据存在不一致，而且又增加了写请求的耗时。

2、第二种方案：异步更新缓存(基于订阅binlog的同步机制)

1.技术整体思路：

MySQL binlog增量订阅消费+消息队列+增量数据更新到redis

1）读Redis：热数据基本都在Redis

2）写MySQL:增删改都是操作MySQL

3）更新Redis数据：MySQ的数据操作binlog，来更新到Redis

2.Redis更新

1）数据操作主要分为两大块：

• 一个是全量(将全部数据一次写入到redis)
• 一个是增量（实时更新）

这里说的是增量,指的是mysql的update、insert、delate变更数据。

2）读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。

这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。

其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。

这里可以结合使用canal(阿里的一款开源框架)，通过该框架可以对MySQL的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。

当然，这里的消息推送工具你也可以采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis

以上文章来源开源中国：地址

作者：瑞查德-Jack

 

缓存一致性的问题是一定会存在的，我们一般说的都是说能达到最终一致性。

对于缓存和数据库的操作，主要有以下两种方式。

先删缓存，再更新数据库

先删除缓存，数据库还没有更新成功，此时如果读取缓存，缓存不存在，去数据库中读取到的是旧值，缓存不一致发生。

解决方案

延时双删

延时双删的方案的思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再sleep一段时间，然后再次删除缓存。

sleep的时间要对业务读写缓存的时间做出评估，sleep时间大于读写缓存的时间即可。

流程如下：

1. 线程1删除缓存，然后去更新数据库
2. 线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存
3. 线程1，根据估算的时间，sleep，由于sleep的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除
4. 如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值

先更新数据库，再删除缓存

如果反过来操作，先更新数据库，再删除缓存呢？

这个就更明显的问题了，更新数据库成功，如果删除缓存失败或者还没有来得及删除，那么，其他线程从缓存中读取到的就是旧值，还是会发生不一致。

解决方案

消息队列

这是网上很多文章里都有写过的方案。但是这个方案的缺陷会更明显一点。

先更新数据库，成功后往消息队列发消息，消费到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。

这个解决方案其实问题更多。

1. 引入消息中间件之后，问题更复杂了，怎么保证消息不丢失更麻烦
2. 就算更新数据库和删除缓存都没有发生问题，消息的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的

进阶版消息队列

为了解决缓存一致性的问题单独引入一个消息队列，太复杂了。

其实，一般大公司本身都会有监听binlog消息的消息队列存在，主要是为了做一些核对的工作。

这样，我们可以借助监听binlog的消息队列来做删除缓存的操作。这样做的好处是，不用你自己引入，侵入到你的业务代码中，中间件帮你做了解耦，同时，中间件的这个东西本身就保证了高可用。

当然，这样消息延迟的问题依然存在，但是相比单纯引入消息队列的做法更好一点。

而且，如果并发不是特别高的话，这种做法的实时性和一致性都还算可以接受的。

其他解决方案

设置缓存过期时间

每次放入缓存的时候，设置一个过期时间，比如5分钟，以后的操作只修改数据库，不操作缓存，等待缓存超时后从数据库重新读取。

如果对于一致性要求不是很高的情况，可以采用这种方案。

这个方案还会有另外一个问题，就是如果数据更新的特别频繁，不一致性的问题就很大了。

在实际生产中，我们有一些活动的缓存数据是使用这种方式处理的。

因为活动并不频繁发生改变，而且对于活动来说，短暂的不一致性并不会有什么大的问题。

为什么是删除，而不是更新缓存？

我们以先更新数据库，再删除缓存来举例。

如果是更新的话，那就是先更新数据库，再更新缓存。

举个例子：如果数据库1小时内更新了1000次，那么缓存也要更新1000次，但是这个缓存可能在1小时内只被读取了1次，那么这1000次的更新有必要吗？

反过来，如果是删除的话，就算数据库更新了1000次，那么也只是做了1次缓存删除，只有当缓存真正被读取的时候才去数据库加载。

总结

首先，我们要明确一点，缓存不是更新，而应该是删除。

删除缓存有两种方式：

1. 先删除缓存，再更新数据库。解决方案是使用延迟双删。
2. 先更新数据库，再删除缓存。解决方案是消息队列或者其他binlog同步，引入消息队列会带来更多的问题，并不推荐直接使用。

针对缓存一致性要求不是很高的场景，那么只通过设置超时时间就可以了。

其实，如果不是很高的并发，无论你选择先删缓存还是后删缓存的方式，都几乎很少能产生这种问题，但是在高并发下，你应该知道怎么解决问题。