文档章节

主从DB与cache一致性

snowing1990
 snowing1990
发布于 2016/03/25 15:20
字数 1544
阅读 136
收藏 9

本文主要讨论这么几个:

1)数据库主从延时为何会导致缓存数据不一致

2)优化思路与方案

 

一、需求缘起

上一篇《缓存架构设计细节二三事》中有一个小优化点,在只有主库时,通过“串行化”的思路可以解决缓存与数据库中数据不一致。引发大家热烈讨论的点是“在主从同步,读写分离的数据库架构下,有可能出现脏数据入缓存的情况,此时串行化方案不再适用了”,这就是本文要讨论的主。

 

二、为什么数据会不一致

为什么会读到脏数据,有这么几种情况:

1)单库情况下,服务层的并发读写,缓存与数据库的操作交叉进行


虽然只有一个DB,在上述诡异异常时序下,也可能脏数据入缓存:

1)请求A发起一个写操作,第一步淘汰了cache,然后这个请求因为各种原因在服务层卡住了(进行大量的业务逻辑计算,例如计算了1秒钟),如上图步骤1

2)请求B发起一个读操作,读cachecache miss,如上图步骤2

3)请求B继续读DB,读出来一个脏数据,然后脏数据入cache,如上图步骤3

4)请求A卡了很久后终于写数据库了,写入了最新的数据,如上图步骤4

这种情况虽然少见,但理论上是存在的 后发起的请求B在先发起的请求A中间完成了。

 

2)主从同步,读写分离的情况下,读从库读到旧数据

在数据库架构做了一主多从,读写分离时,更多的脏数据入缓存是下面这种情况:


1)请求A发起一个写操作,第一步淘汰了cache,如上图步骤1

2)请求A写数据库了,写入了最新的数据,如上图步骤2

3)请求B发起一个读操作,读cachecache miss,如上图步骤3

4)请求B继续读DB,读的是从库,此时主从同步还没有完成,读出来一个脏数据,然后脏数据入cache,如上图步4

5)最后数据库的主从同步完成了,如上图步骤5

这种情况请求A和请求B的时序是完全没有错的,是主动同步的时延(假设延时1秒钟)中间有读请求读从库读到脏数据导致的不一致。

 

那怎么来进行优化呢?


三、不一致优化思路

有同学说“那能不能先操作数据库,再淘汰缓存”,这个是不行的,在《缓存和数据库先操作谁》的文章中介绍过。

 

出现不一致的根本原因:

1)单库情况下,服务层在进行1s的逻辑计算过程中,可能读到旧数据入缓存

2)主从库+读写分离情况下,在1s钟主从同步延时过程中,可能读到旧数据入缓存

既然旧数据就是在那1s的间隙中入缓存的,是不是可以在写请求完成后,再休眠1s,再次淘汰缓存,就能将这1s内写入的脏数据再次淘汰掉呢?

是可以的

 

写请求的步骤由2步升级为3步:

1)先淘汰缓存

2)再写数据库(这两步和原来一样)

3)休眠1秒,再次淘汰缓存

这样的话,1秒内有脏数据如缓存,也会被再次淘汰掉,但带来的是:

1所有的写请求都阻塞了1秒,大大降低了写请求的吞吐量,增长了处理时间,业务上是接受不了的

 

再次分析,其实第二次淘汰缓存是为了保证缓存一致而做的操作,而不是业务要求,所以其实无需等待,用一个异步的timer,或者利用消息总线异步的来做这个事情即可


写请求由2步升级为2.5步:

1)先淘汰缓存

2)再写数据库(这两步和原来一样)

2.5)不再休眠1s,而是往消息总线esb发送一个消息,发送完成之后马上就能返回

这样的话,写请求的处理时间几乎没有增加,这个方法淘汰了缓存两次,因此被称为“缓存双淘汰”法。这个方法付出的代价是,缓存会增加1cache miss(代价几乎可以忽略)。

 

而在下游,有一个异步淘汰缓存的消费者,在接收到消息之后,asy-expire1s之后淘汰缓存。这样,即使1s内有脏数据入缓存,也有机会再次被淘汰掉。

 

上述方案有一个缺点需要业务线的写操作增加一个步骤有没有方案对业务线的代码没有任何入侵呢,是有的,这个方案在《细聊冗余表数据一致性》中也提到过,通过分析线下的binlog来异步淘汰缓存:


业务线的代码就不需要动了,新增一个线下的读binlog的异步淘汰模块,读取到binlog中的数据,异步的淘汰缓存。

 

提问:为什么上文总是说1s,这个1s是怎么来的?

回答:1s只是一个举例,需要根据业务的数据量与并发量,观察主从同步的时延来设定这个值。例如主从同步的时延为200ms,这个异步淘汰cache设置为258ms就是OK的。

 

四、总结

异常时序或者读从库导致脏数据入缓存时,可以用二次异步淘汰缓存双淘汰法来解决缓存与数据库中数据不一致,具体实施至少有三种方案:

1timer异步淘汰(本文没有细讲,本质就是起个线程专门异步二次淘汰缓存)

2总线异步淘汰

3binlog异步淘汰


本文转载自:

共有 人打赏支持
snowing1990
粉丝 4
博文 90
码字总数 2952
作品 0
程序员
数据库设计思路和要点

基本概念 单库 分片 解决单个数据表数据量太大的问题,将单个表的数据均匀的放入多个表中 复制 用于实现主从同步,主库的更新操作(insert/update/delete)向从库(1个或多个)进行同步,同步...

真爱2015
2016/09/28
11
1
数据库软件架构设计些什么

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

懂得-奉献
2016/12/02
18
0
DB主从一致性架构优化4种方法

原创 2016-05-18 58沈剑 架构师之路 需求缘起 大部分互联网的业务都是“读多写少”的场景,数据库层面,读性能往往成为瓶颈。如下图:业界通常采用“一主多从,读写分离,冗余多个读库”的数...

毛爷爷夸我帅
2016/12/06
15
0
数据库之架构:主备+分库?主从+读写分离?

一、数据库架构原则 高可用 高性能 一致性 扩展性 二、常见的架构方案 方案一:主备架构,只有主库提供读写服务,备库冗余作故障转移用    jdbc:mysql://vip:3306/xxdb 高可用分析:高可用...

尜尜人物
08/07
0
0
实录|互联网架构“高可用”在线技术交流

原创 2016-12-06 58沈剑+GitChat 架构师之路 架构师之路架构师之路 微信号 功能介绍 架构师之路,坚持撰写接地气的架构文章 前段时间,受@谢工 邀请,在GitChat平台首发《究竟啥才是互联网架...

毛爷爷夸我帅
2016/12/06
15
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

c语言之内存分配笔记

先看一个数组: short array[5] = {1,2} // 这儿定义的一个int类型的数组,数组第1和第2个元素值是1和2.其余后面默认会给值为0; 或者 short array[] = {1,2};//这儿数组第1和第2个元素,数组...

DannyCoder
今天
2
0
Shell | linux安装包不用选择Y/N的方法

apt-get install -y packageOR echo "y" | sudo apt-get install package

云迹
今天
2
0
Hadoop的大数据生态圈

基于Hadoop的大数据的产品圈 大数据产品的一句话概括 Apache Hadoop: 是Apache开源组织的一个分布式计算开源框架,提供了一个分布式文件系统子项目(HDFS)和支持MapReduce分布式计算的软件架...

zimingforever
今天
5
0
八大包装类型的equals方法

先看其中一个源码 结论:八大包装类型的equals方法都是先判断类型是否相同,不相同则是false,相同则判断值是否相等 注意:包装类型不能直接用==来等值比较,否则编译报错,但是数值的基本类型...

xuklc
今天
2
0
NoSQL , Memcached介绍

什么是NoSQL 非关系型数据库就是NoSQL,关系型数据库代表MySQL 对于关系型数据库来说,是需要把数据存储到库、表、行、字段里,查询的时候根据条件一行一行地去匹配,当量非常大的时候就很耗...

TaoXu
昨天
5
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部