文档章节

缓存与数据库一致性保证 (二)

snowing1990
 snowing1990
发布于 2016/03/17 18:13
字数 2741
阅读 79
收藏 5
点赞 1
评论 0

本文主要讨论这么几个点:

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

2)不一致优化思路

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

 

一、需求缘起

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


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


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

 


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

 

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

 

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

 

二、为什么数据会不一致

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

写流程:

1)先淘汰cache

2)再写db

读流程:

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

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

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

 

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


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

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

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

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

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

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

 

三、不一致优化思路

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

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


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

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

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

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

3.1)最上层是任务队列

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

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

 

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

void work_thread_routine(){

Task t = TaskQueue.pop(); // 获取任务

// 任务逻辑处理,生成sql语句

DBConnection c = CPool.GetDBConnection(); // DB连接池获取一个DB连接

c.execSQL(sql); // 通过DB连接执行sql语句

CPool.PutDBConnection(c); // DB连接放回DB连接池

}

 

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

:不行,因为

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

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

 

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

:不行,原因同上

 

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

:不行,因为

11个服务只有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层面的执行是串行化的,实际上服务是分布式部署的,在全局范围内的访问仍是并行的,怎么解决呢?能不能做到同一个数据的访问一定落到同一个服务呢?

 

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

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


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

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

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

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

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

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

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

 

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

voidwork_thread_routine(){

Task t = TaskQueue.pop(); // 获取任务

// 任务逻辑处理,组成一个网络包packet,调用下游RPC接口

ServiceConnection c = CPool.GetServiceConnection(); // Service连接池获取一个Service连接

c.Send(packet); // 通过Service连接发送报文执行RPC请求

CPool.PutServiceConnection(c); // Service连接放回Service连接池

}

 

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

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

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

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

                                                                                  

五、总结

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

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

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

 

六、遗留

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

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

 

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

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

 

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

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


本文转载自:

共有 人打赏支持
snowing1990
粉丝 4
博文 90
码字总数 2952
作品 0
程序员
数据库软件架构设计些什么

一、基本概念 概念一“单库” 概念二“分片” 分片解决的是“数据量太大”的问题,也就是通常说的“水平切分”。 一旦引入分片,势必有“数据路由”的概念,哪个数据访问哪个库。 路由规则通...

懂得-奉献 ⋅ 2016/12/02 ⋅ 0

如此牛逼?双11背后的秘密-支付宝app双11最佳实践

近来,FF项目的运营活动越来越多,对于架构设计以及程序研发有了更高的要求,参考国内互联网公司对于营销活动app的设计思路,我们找到了最具有代表性的支付宝双11活动,阐述运营活动类高并发...

丁小晶 ⋅ 2016/04/20 ⋅ 0

缓存使用,前台直接操作mysql,后台操作缓存。怎么保证数据一致性

因项目需要主要模块: broker(消息服务器)+web(管理员页面)+。。。。 只有一个mysql数据库,web前台可以直接操作数据库,broker基本全是缓存操作。为了保证数据的一致性,在web前台修改数...

会飞的蝌蚪 ⋅ 2016/03/26 ⋅ 3

高并发和高性能系统中数据一致性问题和应对

读过前面一篇文章《系统架构升级之道,关注关键服务依赖》就知道,我们的应用系统中的关键服务绝大部分都会是对数据库的依赖。 如果只有一个数据库服务器,数据一致性问题也就不存在了。 可是...

一凡Sir ⋅ 前天 ⋅ 0

浅谈 CAP 理论

原文同步至 本文介绍了介绍了分布式系统著名的 CAP 理论。什么是 CAP 理论?为什么说 CAP 只能三选二?了解 CAP 对于系统架构又有什么指导意义?本文将一一作答。 什么是 CAP 理论 在计算机科...

waylau ⋅ 2016/02/28 ⋅ 10

关于数据库主从架构和缓存的一致性问题

看了一些关于分布式缓存一致性的文章,发现淘宝的tair(OSC)的原理可以解决,数据库与缓存的一致性问题,即在更新数据时,首先失效缓存,并未改缓存添加一个版本号,版本号是递增的。这样我们...

手绘灿烂 ⋅ 2016/08/11 ⋅ 0

Apache Ignite事务架构:第三方持久化的事务处理

本文是Ignite事务架构系列的最后一篇文章,在之前的文章中,讨论了与键值API的事务处理有关的一系列主题。 第一篇文章中,主要介绍了二阶段提交协议及其工作方式; 第二篇文章中,介绍了锁模...

李玉珏 ⋅ 04/16 ⋅ 0

Cache和数据库一致性策略-由一篇facebook论文的启发

我们在架构设计中,经常会使用到缓存,例如REDIS,或者MEMcached。 那么问题来了,怎么保证缓存和数据库中数据的一致性呢, 最近看了一篇Facebook的论文,下面是一个比较好的方案。 缓存适用...

小强聊架构 ⋅ 05/18 ⋅ 0

高可用数据库架构实践

数据存储架构 高可用数据库架构实践 单库,不多说了,就是一个库 。一旦引入分片,。 路由规则通常有3种方法: 范围:range 优点:简单,容易扩展 缺点:各库压力不均(新号段更活跃) 哈希:...

陶邦仁 ⋅ 2015/11/13 ⋅ 1

[mongodb文档]分布式一致性

[mongodb文档]分布式一致性(一)[1] 一致性模型对于一个分布式数据库来说是至关重要的。这里我们将专门一个专题的形式来讲解一些主题:例如:针对一些具体的应用场景应该使用什么样的模型。...

nileader ⋅ 2014/06/05 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

高并发之Nginx的限流

首先Nginx的版本号有要求,最低为1.11.5 如果低于这个版本,在Nginx的配置中 upstream web_app { server 到达Ip1:端口 max_conns=10; server 到达Ip2:端口 max_conns=10; } server { listen ...

算法之名 ⋅ 今天 ⋅ 0

Spring | IOC AOP 注解 简单使用

写在前面的话 很久没更新笔记了,有人会抱怨:小冯啊,你是不是在偷懒啊,没有学习了。老哥,真的冤枉:我觉得我自己很菜,还在努力学习呢,正在学习Vue.js做管理系统呢。即便这样,我还是不...

Wenyi_Feng ⋅ 今天 ⋅ 0

博客迁移到 https://www.jianshu.com/u/aa501451a235

博客迁移到 https://www.jianshu.com/u/aa501451a235 本博客不再更新

为为02 ⋅ 今天 ⋅ 0

win10怎么彻底关闭自动更新

win10自带的更新每天都很多,每一次下载都要占用大量网络,而且安装要等得时间也蛮久的。 工具/原料 Win10 方法/步骤 单击左下角开始菜单点击设置图标进入设置界面 在设置窗口中输入“服务”...

阿K1225 ⋅ 今天 ⋅ 0

Elasticsearch 6.3.0 SQL功能使用案例分享

The best elasticsearch highlevel java rest api-----bboss Elasticsearch 6.3.0 官方新推出的SQL检索插件非常不错,本文一个实际案例来介绍其使用方法。 1.代码中的sql检索 @Testpu...

bboss ⋅ 今天 ⋅ 0

informix数据库在linux中的安装以及用java/c/c++访问

一、安装前准备 安装JDK(略) 到IBM官网上下载informix软件:iif.12.10.FC9DE.linux-x86_64.tar放在某个大家都可以访问的目录比如:/mypkg,并解压到该目录下。 我也放到了百度云和天翼云上...

wangxuwei ⋅ 今天 ⋅ 0

PHP语言系统ZBLOG或许无法重现月光博客的闪耀历史[图]

最近在写博客,希望通过自己努力打造一个优秀的教育类主题博客,名动江湖,但是问题来了,现在写博客还有前途吗?面对强大的自媒体站点围剿,还有信心和可能型吗? 至于程序部分,我选择了P...

原创小博客 ⋅ 今天 ⋅ 0

IntelliJ IDEA 2018.1新特性

工欲善其事必先利其器,如果有一款IDE可以让你更高效地专注于开发以及源码阅读,为什么不试一试? 本文转载自:netty技术内幕 3月27日,jetbrains正式发布期待已久的IntelliJ IDEA 2018.1,再...

Romane ⋅ 今天 ⋅ 0

浅谈设计模式之工厂模式

工厂模式(Factory Pattern)是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。 在工厂模式中,我们在创建对象时不会对客户端暴露创建逻...

佛系程序猿灬 ⋅ 今天 ⋅ 0

Dockerfile基础命令总结

FROM 指定使用的基础base image FROM scratch # 制作base image ,不使用任何基础imageFROM centos # 使用base imageFROM ubuntu:14.04 尽量使用官方的base image,为了安全 LABEL 描述作...

ExtreU ⋅ 昨天 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部