看完这篇,你还不能理解 ‘数据库架构’?趁早回家吧

来源:http://rrd.me/ep46N

一、数据库架构原则

  1. 高可用
  2. 高性能
  3. 一致性
  4. 扩展性

二、常见的架构方案

方案一:主备架构,只有主库提供读写服务,备库冗余作故障转移用

jdbc:mysql://vip:3306/xxdb

1、高可用分析:高可用,主库挂了,keepalive(只是一种工具)会自动切换到备库。这个过程对业务层是透明的,无需修改代码或配置。 

2、高性能分析:读写都操作主库,很容易产生瓶颈。大部分互联网应用读多写少,读会先成为瓶颈,进而影响写性能。另外,备库只是单纯的备份,资源利用率50%,这点方案二可解决。 

3、一致性分析:读写都操作主库,不存在数据一致性问题。 

4、扩展性分析:无法通过加从库来扩展读性能,进而提高整体性能。 

5、可落地分析:两点影响落地使用。第一,性能一般,这点可以通过建立高效的索引和引入缓存来增加读性能,进而提高性能。这也是通用的方案。第二,扩展性差,这点可以通过分库分表来扩展。

方案二:双主架构,两个主库同时提供服务,负载均衡

jdbc:mysql://vip:3306/xxdb

1、高可用分析:高可用,一个主库挂了,不影响另一台主库提供服务。这个过程对业务层是透明的,无需修改代码或配置。 

2、高性能分析:读写性能相比于方案一都得到提升,提升一倍。

3、一致性分析:存在数据一致性问题。请看,一致性解决方案。 

4、扩展性分析:当然可以扩展成三主循环,但笔者不建议(会多一层数据同步,这样同步的时间会更长)。如果非得在数据库架构层面扩展的话,扩展为方案四。 

5、可落地分析:两点影响落地使用。第一,数据一致性问题,一致性解决方案可解决问题第二,主键冲突问题,ID统一地由分布式ID生成服务来生成可解决问题。

方案三:主从架构,一主多从,读写分离

jdbc:mysql://master-ip:3306/xxdbjdbc:mysql://slave1-ip:3306/xxdbjdbc:mysql://slave2-ip:3306/xxdb

1、高可用分析:主库单点,从库高可用。一旦主库挂了,写服务也就无法提供。 

2、高性能分析:大部分互联网应用读多写少,读会先成为瓶颈,进而影响整体性能。读的性能提高了,整体性能也提高了。另外,主库可以不用索引,线上从库和线下从库也可以建立不同的索引(线上从库如果有多个还是要建立相同的索引,不然得不偿失;线下从库是平时开发人员排查线上问题时查的库,可以建更多的索引)。 

3、一致性分析:存在数据一致性问题。请看,一致性解决方案。 

4、扩展性分析:可以通过加从库来扩展读性能,进而提高整体性能。(带来的问题是,从库越多需要从主库拉取binlog日志的端就越多,进而影响主库的性能,并且数据同步完成的时间也会更长) 

5、可落地分析:两点影响落地使用。第一,数据一致性问题,一致性解决方案可解决问题第二,主库单点问题,笔者暂时没想到很好的解决方案。

注:思考一个问题,一台从库挂了会怎样?读写分离之读的负载均衡策略怎么容错?

方案四:双主+主从架构,看似完美的方案

jdbc:mysql://vip:3306/xxdbjdbc:mysql://slave1-ip:3306/xxdbjdbc:mysql://slave2-ip:3306/xxdb

1、高可用分析:高可用。 

2、高性能分析:高性能。 

3、一致性分析:存在数据一致性问题。请看,一致性解决方案

4、扩展性分析:可以通过加从库来扩展读性能,进而提高整体性能。(带来的问题同方案二) 

5、可落地分析:同方案二,但数据同步又多了一层,数据延迟更严重

三、一致性解决方案

第一类:主库和从库一致性解决方案

注:图中圈出的是数据同步的地方,数据同步(从库从主库拉取binlog日志,再执行一遍)是需要时间的,这个同步时间内主库和从库的数据会存在不一致的情况。如果同步过程中有读请求,那么读到的就是从库中的老数据。如下图。

既然知道了数据不一致性产生的原因,有下面几个解决方案供参考:

1、直接忽略,如果业务允许延时存在,那么就不去管它。 

2、强制读主,采用主备架构方案,读写都走主库。用缓存来扩展数据库读性能 。有一点需要知道:如果缓存挂了,可能会产生雪崩现象,不过一般分布式缓存都是高可用的。

3、选择读主,写操作时根据库+表+业务特征生成一个key放到Cache里并设置超时时间(大于等于主从数据同步时间)。读请求时,同样的方式生成key先去查Cache,再判断是否命中。若命中,则读主库,否则读从库。代价是多了一次缓存读写,基本可以忽略。

4、半同步复制,等主从同步完成,写请求才返回。就是大家常说的“半同步复制”semi-sync。这可以利用数据库原生功能,实现比较简单。代价是写请求时延增长,吞吐量降低。 

5、数据库中间件,引入开源(mycat等)或自研的数据库中间层。个人理解,思路同选择读主。数据库中间件的成本比较高,并且还多引入了一层。**

**

第二类:DB和缓存一致性解决方案

先来看一下常用的缓存使用方式:

第一步:淘汰缓存;

第二步:写入数据库;

第三步:读取缓存?返回:读取数据库;

第四步:读取数据库后写入缓存。

注:如果按照这种方式,图一,不会产生DB和缓存不一致问题;图二,会产生DB和缓存不一致问题,即4.read先于3.sync执行。如果不做处理,缓存里的数据可能一直是脏数据。解决方式如下:

注:设置缓存时,一定要加上有效时间,以防延时淘汰缓存失败的情况!

四、个人的一些见解

1、架构演变

1、架构演变一:方案一 -> 方案一+分库分表 -> 方案二+分库分表 -> 方案四+分库分表; 

2、架构演变二:方案一 -> 方案一+分库分表 -> 方案三+分库分表 -> 方案四+分库分表; 

3、架构演变三:方案一 -> 方案二 -> 方案四 -> 方案四+分库分表; 

4、架构演变四:方案一 -> 方案三 -> 方案四 -> 方案四+分库分表;

2、个人见解

1、加缓存和索引是通用的提升数据库性能的方式; 

2、分库分表带来的好处是巨大的,但同样也会带来一些问题,详见前日推文。

3、不管是主备+分库分表还是主从+读写分离+分库分表,都要考虑具体的业务场景。绝大部分的数据库架构还是采用方案一和方案一+分库分表,只有极少部分用方案三+读写分离+分库分表。另外,阿里云提供的数据库云服务也都是主备方案,要想主从+读写分离需要二次架构。 

4、记住一句话:不考虑业务场景的架构都是耍流氓。朕已阅 

Image placeholder
waitingsnow
未设置
  60人点赞

没有讨论,发表一下自己的看法吧

推荐文章
阿里巴巴为什么能抗住90秒100亿?看完这篇你就明白了!

1、概述本文以淘宝作为例子,介绍从一百个并发到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构设计的原则。2、

巨杉TechDay回顾 | 与携程、巨杉、知乎大牛一起探寻DT时代数据库架构之道

数据,已成众多企业的核心资产。如今企业越来越懂得数据的重要性,也愈发清楚数据将为公司带来的巨大价值。在物联网、AI等技术的普及下,数据井喷仍在持续进行,如何更好地管理和使用这些“无穷无尽”的数据,则成

工商银行MySQL数据库架构解密

本文根据DTCC数据库大会分享内容整理而成,将介绍工行IT架构转型中传统OLTP数据库架构面临的挑战和诉求,构建基于MySQL分布式企业级解决方案实践历程,包括技术选择、高可用设计、两地三中心容灾、运

看完秒变5G专家!关于5G,你必须知道的事儿……

本文转自|鲜枣课堂   什么是5G    5G,就是5thGenerationMobileNetworks(第五代移动通信网络),也可以称为5thGenerationWirelessSystems(第

实现人工智能落地 你还差一个“数据分析流水线”的距离

在智慧生产场景,生产制造商可以在生产线上利用深度学习,尤其是图像识别,将产品的质量检测自动化。比如自动检测产品表面有没有划伤、有没有零部件的缺失、有没有标签的错位。研究表明,相比人工检测,智慧检测可以

死磕Synchronized底层实现,面试你还怕什么?

关于 synchronized 的底层实现,网上有很多文章了。但是很多文章要么作者根本没看代码,仅仅是根据网上其他文章总结、照搬而成,难免有些错误;要么很多点都是一笔带过,对于为什么这样实现没有一个说

面向回家编程!GitHub标星两万的”Python抢票教程”,我们先帮你跑了一遍

盼望着,盼望着,春节的脚步近了,然而,每年到这个时候,最难的,莫过于一张回家的火车票。据悉,今年春运期间,全国铁路发送旅客人次同比将增长8.0%。达到4.4亿人次,2020年铁路春运自1月10日开始,

看完知乎轮子哥的编程之路,我只想说,收下我的膝盖…

vczh,本名陈梓瀚,因知乎的个人信息介绍上写有“专业造轮子”,所以江湖人称“轮子哥”。vczh大学时代就在微软实习,毕业后即加入微软。开始时是在微软上海,后来进入北京的微软亚洲研究院。现已移居美国西

GitHub上标星1.5w,被B站使用,flv.js开源作者月薪还不到5k!学历对程序员有多重要?

大数据文摘出品作者:刘俊寰上周,文摘菌向大家介绍了在美国当数据科学家的年薪水平,发现科学家们的整体薪资走势虽然有所下降,但是年薪中位数保持在12万美元左右。同一时间,知乎上一个很老的话题忽然被重提,也

做深度学习这么多年还不会挑GPU?这儿有份选购全攻略

大数据文摘出品来源:timdettmers编译:刘佳玮、钱天培深度学习是一个对算力要求很高的领域。GPU的选择将从根本上决定你的深度学习体验。一个好的GPU可以让你快速获得实践经验,而这些经验是正是建

从理论到案例,请收下这篇 Nginx 监控运维干货

Nginx(“enginex”)是一个开源、免费、高性能的HTTP和反向代理服务器,也可以用于IMAP/POP3代理服务器。充分利用Nginx的特性,可以有效解决流量高并发请求、cc攻击等问题。本文

如果有人再问你怎么实现分布式延时消息,这篇文章丢给他

1.背景上篇文章介绍了RocketMQ整体架构和原理有兴趣的可以阅读一下,在这篇文章中的延时消息部分,我写道开源版的RocketMQ只提供了18个层级的消息队列延时,这个功能在开源版中显得特别鸡肋,但

DTCC | 云数据库时代已来,你准备好了吗?

作为基础软件之一,数据库一直是企业IT系统的核心,过去数十年,数据库技术发展缓慢。而随着云计算的到来及相关技术的不断成熟推动了数据库行业的快速发展,传统数据库铁打的防线也正在被撕裂。截至目前,全球主流

万字详解Oracle架构、原理、进程,学会世间再无复杂架构

学习是一个循序渐进的过程,从面到点、从宏观到微观,逐步渗透,各个击破,对于Oracle, 怎么样从宏观上来理解呢?先来看一个图,这个图取自于教材,这个图对于从整体上理解ORACLE 的体系结构组件,非

架构转型先行——金融业务场景下的新一代架构实践

  赵勇中国农业银行研发中心架构管理办公室主任工程师中国农业银行研发中心架构管理办公室主任工程师,十年以上金融行业信息化架构设计与管控经验。历经互联网金融、两地三中心、分布式核心银行等大型银行系统工程

数字转型 架构演进 2019中国系统架构师大会盛大召开

2019年10月31日~11月2日,由IT168旗下ChinaUnix社区主办的第十一届中国系统架构师大会(SACC2019)在北京隆重召开。自2009年举办以来,大会云集了国内CTO、研发总监、高级

阿里支付宝架构师:谈谈我眼中的高并发架构【好文】

来源:my.oschina.net/u/3772106/blog/1793561前言高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。为了让业务可以流畅的运行并且

架构师眼中的高并发架构

前言高并发经常发生在有大活跃用户量和用户高聚集的业务场景中,如:秒杀活动、定时领取红包等。为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己

SOA架构和微服务架构的区别是什么?

来源:rrd.me/fqdANSOA架构和微服务架构的区别首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。1.SOA

Nebula 架构剖析系列(二)图数据库的查询引擎设计

摘要上文(存储篇)说到数据库重要的两部分为存储和计算,本篇内容为你解读图数据库Nebula在查询引擎QueryEngine方面的设计实践。在Nebula中,QueryEngine是用来处理Nebula

数据库之互联网常用架构方案一览

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

腾讯数据库专家雷海林分享智能运维架构

2019年5月8日-10日的DTCC2019年中国数据库大会上,腾讯云数据库专家工程师雷海林首受邀做了主题为《TDSQL智能运维平台-扁鹊架构与实践》的技术分享,以下为大会现场演讲实录。雷海林在大会现

如何理解腾讯云数据库战略升级?

近日,腾讯云数据库在京正式启动战略升级,宣布未来将聚焦云原生、自治、超融合三大战略方向,以用户为中心,联接未来。并在现场面向全球用户同步发布五大战略级新品,包括数据库智能管家DBbrain、云数据库T

Elasticsearch 与传统关系型数据库的对比、倒排索引原理解析

Elasticsearch和传统关系型数据库的对比Elasticsearch中的概念与关系型数据库对比 RelationalDB Databases Tables Rows Columns 关系

大数据时代,数据湖并不能完全取代数据仓库

数据仓库为组织了解其历史业务表现和推动持续运营提供了一个接入窗口,为数据分析师和业务用户提供了诸如客户行为、业务趋势、运营效率和销售等方面的信息。尽管出现了基于Hadoop和其他一些大数据技术的数据湖