AIQ | redis 缓存与数据库一致性保证解决方案讨论



转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com

AIQ 机器学习大数据 知乎专栏 点击关注

本文主要讨论这么几个问题:

1. 啥时候数据库和缓存中的数据会不一致

2. 不一致优化思路

3. 如何保证数据库与缓存的一致性

1需求缘起

上一篇《缓存架构设计细节二三事》引起了广泛的讨论,其中有一个结论:当数据发生变化时,“先淘汰缓存,再修改数据库” 这个点是大家讨论的最多的。

(《缓存架构设计细节二三事》链接—http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=404087915&idx=1&sn=075664193f334874a3fc87fd4f712ebc&scene=21#wechat_redirect)

上篇文章得出这个结论的依据是,由于操作缓存与操作数据库不是原子的,非常有可能出现执行失败。

 


  

假设先写数据库,再淘汰缓存:第一步写数据库操作成功,第二步淘汰缓存失败,则会出现 DB 中是新数据,Cache 中是旧数据,数据不一致【如上图:db 中是新数据,cache 中是旧数据】。

 


  

假设先淘汰缓存,再写数据库:第一步淘汰缓存成功,第二步写数据库失败,则只会引发一次 Cache miss【如上图:cache 中无数据,db 中是旧数据】。

 

结论:先淘汰缓存,再写数据库。

 

引发大家热烈讨论的点是“先操作缓存,在写数据库成功之前,如果有读请求发生,可能导致旧数据入缓存,引发数据不一致”,这就是本文要讨论的主题。

 

2为什么数据会不一致

回顾一下上一篇文章中对缓存、数据库进行读写操作的流程。

写流程:

(1)先淘汰 cache

(2)再写 db

读流程:

(1)先读 cache,如果数据命中 hit 则返回

(2)如果数据未命中 miss 则读 db

(3)将 db 中读取出来的数据入缓存

 

什么情况下可能出现缓存和数据库中数据不一致呢?

 

在分布式环境下,数据的读写都是并发的,上游有多个应用,通过一个服务的多个部署(为了保证可用性,一定是部署多份的),对同一个数据进行读写**,在数据库层面并发的读写并不能保证完成顺序,** 也就是说后发出的读请求很可能先完成(读出脏数据):

(a)发生了写请求 A,A 的第一步淘汰了 cache(如上图中的 1)

(b)A 的第二步写数据库,发出修改请求(如上图中的 2)

(c)发生了读请求 B,B 的第一步读取 cache,发现 cache 中是空的(如上图中的步骤 3)

(d)B 的第二步读取数据库,发出读取请求,此时A 的第二步写数据还没完成,读出了一个脏数据放入 cache(如上图中的步骤 4)

在数据库层面,后发出的请求 4 比先发出的请求 2 先完成了,读出了脏数据,脏数据又入了缓存,缓存与数据库中的数据不一致出现了。

3不一致优化思路

能否做到先发出的请求一定先执行完成呢? 常见的思路是“串行化”,今天将和大家一起探讨“串行化”这个点。

先一起细看一下,在一个服务中,并发的多个读写 SQL 一般是怎么执行的


 

上图是一个 service 服务的上下游及服务内部详细展开,细节如下:

(1)service 的上游是多个业务应用,上游发起请求对同一个数据并发的进行读写操作,上例中并发进行了一个 uid=1 的余额修改(写)操作与 uid=1 的余额查询(读)操作

(2)service 的下游是数据库 DB,假设只读写一个 DB

(3)中间是服务层 service,它又分为了这么几个部分

  ①最上层是任务队列

  ②中间是工作线程,每个工作线程完成实际的工作任务,典型的工作任务是通过数据库连接池读写数据库

  ③最下层是数据库连接池,所有的 SQL 语句都是通过数据库连接池发往数据库去执行的

 工作线程的典型工作流是这样的:


提问任务队列其实已经做了任务串行化的工作,能否保证任务不并发执行?

答:不行,因为

(1)1 个服务有多个工作线程,串行弹出的任务会被并行执行;

(2)1 个服务有多个数据库连接,每个工作线程获取不同的数据库连接会在 DB 层面并发执行。

 

提问假设服务只部署一份,能否保证任务不并发执行?

答:不行,原因同上。

 

提问假设 1 个服务只有 1 条数据库连接,能否保证任务不并发执行?

答:不行,因为:

(1)1 个服务只有 1 条数据库连接,只能保证在一个服务器上的请求在数据库层面是串行执行的

(2)因为服务是分布式部署的,多个服务上的请求在数据库层面仍可能是并发执行的

 

提问假设服务只部署一份,且 1 个服务只有 1 条连接,能否保证任务不并发执行?

答:可以,全局来看请求是串行执行的,吞吐量很低,并且服务无法保证可用性

 

完了,看似无望了。

1)任务队列不能保证串行化

2)单服务多数据库连接不能保证串行化

3)多服务单数据库连接不能保证串行化

4)单服务单数据库连接可能保证串行化,但吞吐量级低,且不能保证服务的可用性,几乎不可行,那是否还有解?

 

退一步想,其实不需要让全局的请求串行化,而只需要“让同一个数据的访问能串行化”就行。

在一个服务内,如何做到“让同一个数据的访问串行化”,只需要“让同一个数据的访问通过同一条 DB 连接执行”就行。

如何做到“让同一个数据的访问通过同一条 DB 连接执行”,只需要“在 DB 连接池层面稍微修改,按数据取连接即可”。

获取 DB 连接的 CPool.GetDBConnection()【返回任何一个可用 DB 连接】改为

CPool.GetDBConnection(longid)【返回 id 取模相关联的 DB 连接】

这个修改的好处是:

(1)简单,只需要修改 DB 连接池实现,以及 DB 连接获取处

(2)连接池的修改不需要关注业务,传入的 id 是什么含义连接池不关注,直接按照 id 取模返回 DB 连接即可

(3)可以适用多种业务场景,取用户数据业务传入 user-id 取连接,取订单数据业务传入 order-id 取连接即可

这样的话,就能够保证同一个数据例如 uid 在数据库层面的执行一定是串行的

 

稍等稍等,服务可是部署了很多份的,上述方案只能保证同一个数据在一个服务上的访问,在 DB 层面的执行是串行化的,实际上服务是分布式部署的,在全局范围内的访问仍是并行的,怎么解决呢?能不能做到同一个数据的访问一定落到同一个服务呢?

 

4能否做到同一个数据的访问落在同一个服务上?

上面分析了服务层 service 的上下游及内部结构,再一起看一下应用层上下游及内部结构


 

上图是一个业务应用的上下游及服务内部详细展开,细节如下:

(1)业务应用的上游不确定是啥,可能是直接是 http 请求,可能也是一个服务的上游调用

(2)业务应用的下游是多个服务 service

(3)中间是业务应用,它又分为了这么几个部分

  ①最上层是任务队列【或许 web-server 例如 tomcat 帮你干了这个事情了】

  ②中间是工作线程【或许 web-server 的工作线程或者 cgi 工作线程帮你干了线程分派这个事情了】,每个工作线程完成实际的业务任务,典型的工作任务是通过服务连接池进行 RPC 调用

  ③最下层是服务连接池,所有的 RPC 调用都是通过服务连接池往下游服务去发包执行的

 

工作线程的典型工作流是这样的:



 

似曾相识吧?没错,只要对服务连接池进行少量改动:

获取 Service 连接的 CPool.GetServiceConnection()【返回任何一个可用 Service 连接】改为

CPool.GetServiceConnection(longid)【返回 id 取模相关联的 Service 连接】

这样的话,就能够保证同一个数据例如 uid 的请求落到同一个服务 Service 上。

5总结

由于数据库层面的读写并发,引发的数据库与缓存数据不一致的问题(本质是后发生的读请求先返回了),可能通过两个小的改动解决:

(1)修改服务 Service 连接池,id 取模选取服务连接,能够保证同一个数据的读写都落在同一个后端服务上;

(2)修改数据库 DB 连接池,id 取模选取 DB 连接,能够保证同一个数据的读写在数据库层面是串行的。

6遗留问题

提问取模访问服务是否会影响服务的可用性?

答:不会,当有下游服务挂掉的时候,服务连接池能够检测到连接的可用性,取模时要把不可用的服务连接排除掉。

 

提问取模访问服务与 取模访问 DB,是否会影响各连接上请求的负载均衡?

答:不会,只要数据访问 id 是均衡的,从全局来看,由 id 取模获取各连接的概率也是均等的,即负载是均衡的。

 

提问要是数据库的架构做了主从同步,读写分离:写请求写主库,读请求读从库也有可能导致缓存中进入脏数据呀,这种情况怎么解决呢(读写请求根本不落在同一个 DB 上,并且读写 DB 有同步时延)?

答:下一篇文章和大家分享。

作者介绍   58 沈剑


  • 在百度、58 同城做过技术,现在在 58 到家负责一些后端的部门,本质是程序员,常在深夜写写技术文章。公众号“架构师之路”运营者,专注于分享来自一线的,可落地的,原创的架构技术文章。

 平台授权转载

 来源:架构师之路

作者:58 沈剑

 原文链接:http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=404202261&idx=1&sn=1b8254ba5013952923bdc21e0579108e&scene=1&srcid=0328QOM7SGt48P7QBArSF2Ql#wechat_redirect


更多高质资源 尽在AIQ 机器学习大数据 知乎专栏 点击关注

转载请注明 AIQ - 最专业的机器学习大数据社区  http://www.6aiq.com