What, 数据库脑裂了?

Posted dbLenis

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了What, 数据库脑裂了?相关的知识,希望对你有一定的参考价值。

点击蓝色“有关SQL”关注我哟

加个“星标”,天天与10000人一起快乐成长

在朋友圈,我经常唠叨,数据中心的两地三中心架构。

郑州的期货交易所,就是采用了这样的架构,在三次暴雨袭击后,仍能屹立不倒,从容不迫服务每笔交易。详细请戳这里:

郑州暴雨肆虐,商交所数据中心屹立不倒,它做对了什么?

两地三中心

在这里,先回顾下郑交所(郑州期货交易所)两地三中心架构:


两地三中心,以郑交所为例,两地便是“郑州”和“上海”,三中心,便是“郑东区数据中心”、“华融融达期货郑州总部”和“上海数据中心”。

两地三中心的架构,可以预防本地(郑州)级别的小概率自然灾害,还可以预防全国性的自然灾害。能将郑州和上海同时都端掉的自然灾害或人为行为,几乎不存在。除非是像电影《后天》里面那种极端事件。

复制是基础

对于我们这些技术理工宅来说,感兴趣的莫过于这里面的数据复制技术。同城之间采用了什么复制技术,异地之间又采用了什么复制模式,究竟如何保持三中心的数据一致,每个技术人都迫不及待的想知道。

我没有郑交所的工作经历,并不知道具体内幕。但我知道,数据库的复制,逃不过这几类:

  • Leader-based replication 主从复制

  • MultiLeader-based replication 多主复制

  • Leaderless-based replication 无主复制

最常用的一类,当属主从复制。


电影,硬核复制玩家

小时候,村里经常会来放露天电影。播映小组临时搭个台面,全村人都挤到一块儿,嗑着瓜子,喝着汽水,早早扎个好地儿,一站连看1-2小时,都不叫腿酸的。


露天电影及其考验耳朵,在后排的,听不清;站前排的,又吵的扎耳朵,观感体验不是很好。每场电影的人数,虽说没人管,其实际上是有限制的。

放露天电影,相当于是用户在读取数据。

要想让观众看得爽,收更多的电影入场费,怎么办呢?把电影多复制几份,找多块场地播放。村头一场,村尾同时办一场。分流后,不仅总人数多了,观众体验也极强。看了还想看!

所以数据库想要伺候越来越多的读请求,也只要多复制几份,强子说的“多加三倍服务器”,确实没毛病。

电影院越开越大,屏幕越来越多,满足上千人观影同时,还不影响效果。这就是多副本的好处。

数据库也同理。

直播,复制新玩家

但电影拷贝是冷拷贝,在复制完主盘之后,所有的副本都是一致相同的。所以没什么实时的障碍。

拿体育赛事,比如京东奥运直播来说,实时性就要求高了。可以与现场稍有时差,但总不能太大。现场中国队都拿20枚金牌了,转播到国内,我们还在庆祝第10枚金牌,发个朋友圈,不是被笑死!

比如,苏神在跑9.83秒那场,正跟着苏神一起冲冲冲的时候,突然画面嘎嘣下,刹那间,仿佛宇宙毁灭,成了一束光。晃过神,才发现视频雪花了。那不是要急死人,问候下转播台的祖宗长辈,就不过分了!

数据库玩复制,俺也一样

数据库也一样,在多副本开启的同时,总不能让用户老看昨天的数据。也不能说,用户在北京发条微博,回到上海就看不见了。

主从复制,要解决两件事:

  • 数据复制到多个数据库

  • 保持多个副本数据的一致性

这两件事,带来的好处是:

  • 读写分离,提高吞吐

  • 切换故障的数据库


复制,提高吞吐

由上,主从库之间,采用同步复制,时刻保持一致。主库承担写,从库承载读。原本一台库要处理读写,现在分成2台。响应更快,吞吐量(处理的请求)更高。

但是,这样设计,一定就很完美么?显然不是!全是坑

首先,只有一个主库时,主库日志写入,更新就算成功。而现在主从架构,还要等从库完成日志写入,主库才能提交日志。

1-5个步骤里,任何一个失败,本次提交,就算失败。增加一个节点,意味着增加一个失败因子。从库的反应只要稍差那么点时间,主库就会认为从库挂了,从而回滚操作。

当再增加“从从”库,虽说能服务的用户更多,但等待时间也会线性加倍延长,而且大有提高更新失败的概率。


当每一个从库都采用同步策略时,仅等待日志确认,都可以杀死一大批请求。而当采用异步时,从从从库的数据又丧失了与主库的一致性。

因此,折中的办法就是一台从库采用同步,其他从库则采用异步复制数据。

复制,一个倒下去,另一个站起来

数据复制的另一个好处,提供高可用。

当主库下线时,从库接替主库,开始服务用户请求。原下线的主库,此时变成了从库。等再次回来时,新主库把下线时间内的数据更新,补回老主库去。

这样,虽说服务速度慢下来,始终还能保持系统可用。

好玩的是,等老主库上线后,因各种原因,比如网络抖动暂时中断,造成新主库与老主库之间通信受阻,两边都认为自己是主库,此时便产生了脑裂(split brain),即新旧主库都接受写入。

该怎么办呢,咳咳,我们下回再讲!

--完--

往期精彩:

本号精华合集(三)

外企一道 SQL 面试题,刷掉 494 名候选人

我在面试数据库工程师候选人时,常问的一些题

零基础 SQL 数据库小白,从入门到精通的学习路线与书单

以上是关于What, 数据库脑裂了?的主要内容,如果未能解决你的问题,请参考以下文章

Redis学习笔记33——脑裂:奇怪的数据丢失

Redis学习笔记33——脑裂:奇怪的数据丢失

Redis学习笔记33——脑裂:奇怪的数据丢失

Redis脑裂为何会导致数据丢失?

Redis脑裂为何会导致数据丢失?

Redis脑裂为何会导致数据丢失?