Redis 和 Mysql 数据库数据如何保持一致性

在高并发的业务场景下,数据库大多数情况都是用户并发访问最薄弱的环节。所以,就需要使用redis做一个缓冲操作,让请求先访问到redis,而不是直接访问Mysql等数据库。这样可以大大缓解数据库的压力。具体业务流程如下:

        读取缓存步骤一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存和数据库间的数据一致性问题。不管是先写数据库,再删除缓存;还是先删除缓存,再写库,都有可能出现数据不一致的情况。举个例子:

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

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

        因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题。如何解决?这里给出两个解决方案,先易后难,结合业务和技术代价选择使用。

一、 延时双删策略

        在写库前后都进行redis.del(key)操作,并且设定合理的超时时间。具体步骤是:

        1)先删除缓存

        2)再写数据库

        3)休眠500毫秒(根据具体的业务时间来定)

        4)再次删除缓存。

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

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

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

二、设置缓存的过期时间

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

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

三、如何写完数据库后,再次删除缓存成功?

        上述的方案有一个缺点,那就是操作完数据库后,由于种种原因删除缓存失败,这时,可能就会出现数据不一致的情况。这里,我们需要提供一个保障重试的方案。

1、方案一具体流程

        (1)更新数据库数据; 

        (2)缓存因为种种问题删除失败;

        (3)将需要删除的key发送至消息队列;

        (4)自己消费消息,获得需要删除的key;

        (5)继续重试删除操作,直到成功。

        然而,该方案有一个缺点,对业务线代码造成大量的侵入。于是有了方案二,在方案二中,启动一个订阅程序去订阅数据库的binlog,获得需要操作的数据。在应用程序中,另起一段程序,获得这个订阅程序传来的信息,进行删除缓存操作。 

2、方案二具体流程

        (1)更新数据库数据;

        (2)数据库会将操作信息写入binlog日志当中;

        (3)订阅程序提取出所需要的数据以及key; 

        (4)另起一段非业务代码,获得该信息;

        (5)尝试删除缓存操作,发现删除失败; 

        (6)将这些信息发送至消息队列;

        (7)重新从消息队列中获得该数据,重试操作。



作者:守住阳光
链接:https://www.jianshu.com/p/2edbb48604bd
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。