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

1. 数据库架构原则

1. 高可用

2. 高性能

3. 一致性

4. 扩展性

2. 常见的架构方案

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

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执行。如果不做处理,缓存里的数据可能一直是脏数据。解决方式如下:

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

4. 个人的一些见解

1、架构演变

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

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

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

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

2、个人见解

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

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

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

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

作者:尜尜人物来源:https://www.cnblogs.com/littlecharacter/p/9342129.html

Image placeholder
IT头条
未设置
  47人点赞

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

推荐文章
高可用架构实例:在多云和多区域中穿行

Auth0为所有技术栈上的任一平台(移动,Web,本机)应用程序提供身份验证,授权和单点登录服务。身份验证对绝大多数应用程序至关重要。我们从一开始就设计了Auth0,以便它可以在任何地方运行:在我们的

会员服务在高可用架构的实战探索

概述很多互联网公司在发展过程中大多出现过多次机房网络故障的情形,如果发生故障,一般需要动用整个IT部门的人力进行流量切换和客诉处理。为了避免此类情形的发生,公司计划进行服务的高可用建设。会员部门持续跟

对话蒋杰、丁奇,腾讯云数据库之路

此前,笔者曾经就腾讯云数据库战略升级一事写过一篇文章,对腾讯云数据库聚焦“云原生”“自治”“超融合”三大方向背后原因,以及怎样理解腾讯云数据库战略升级与五大新品、三大方向的关系进行了分析。近日,在腾讯

互联网行业巨头的职级薪资揭秘

以BAT为代表的互联网行业巨头,其职级薪资一直都为业内所津津乐道。相信大家对BAT的职级薪资都十分好奇,今天小编就来为大家揭秘互联网行业巨头的职级薪资。其实像阿里巴巴、腾讯和百度这样的互联网巨头,其职

漫画 | 互联网公司面试黑话图鉴:个个奥斯卡!

作者:阿波漫画:最新热歌慢摇面试如一座冰山水面之上的10%是台词水面之下的90%是潜台词看不懂面试的潜台词离沉船就不远了在信任与演技错综复杂的职场中读懂面试潜台词是你成就职场霸业的第一步这份面试黑话图

互联网是如何把“原始人”逼成“机器人”

【导读】互联网快速发展的这十多年,我们见证了企业软件架构的多次迭代和演变。初期阶段都使用JSP+Servlet,工程师感觉代码直接写在jsp页面上不优雅,也不方便调试。后续发展为JSP+Javabea

互联网公司忽悠员工的黑话

作者推特:@siyecao66据说这些是互联网公司招工时忽悠的黑话,大家来看看是不是真的?再列举几个黑话:老板:市场很大=我还不知道怎么赚钱有一定的用户基础= 建立了QQ群和微信群自主研发的系统=XX

腾讯汤道生:产业互联网时代,安全成为CEO的一把手工程

产业互联网日益成为众多行业实现转型,获得发展新动能的趋势性选择,政务、金融、医疗、出行、教育、零售、工业等垂直领域,正在全面拥抱产业互联网。网络安全作为互联网的基础保障,在产业互联网发展和企业数字化升

格创东智聚焦生产现场入局工业互联网平台

2018年是国内工业互联网的开局之年,当前工业互联网正在如火如荼进行。一方面国家政策大力推动,国务院、工信部到各省都出台了相关的规划和指导,另一方面传统企业需要升级,而工业互联网是产业互联网的重要一环

离开互联网大厂的年轻人都去了哪儿?

在签完所有的离职手续后,Celine离开了公司。这是Celine在腾讯的第5年。从入职的那天起,这份工作几乎满足了她对于“完美工作”的所有定义。“大平台、高起点、匹配一线城市房价的高收入……”,Cel

互联网从此没有 BAT

根据Wind数据截止2019年8月30日,中国十大互联网上市公司排名中,百度排名第6位市值365亿美元,阿里巴巴排名第一市值高达4499亿美元,腾讯排名第二市值3951亿美元。01.最新梯队排在第一的

准独角兽雷鸟科技出席SACC2019,讲述AI在场景互联网下的创新革命

10月31日至11月2日,由IT168旗下ITPUB企业社区平台主办的第十一届中国系统架构师大会(SACC2019)在北京召开。作为国内最具价值的技术交流盛会,也少不了今年热门的智慧大屏话题。据了解,

百度会跌出中国互联网前十吗?

北京时间8月20日早上,百度公布了其2019年Q2财报。财报显示,按照美国通用会计准则(GAAP)计算,百度Q2的总营收为263亿元(38.4亿美元),同比增长1%,高于分析师预期;归属于百度的净利润

互联网大佬学历、背景大揭秘,看看是你的老乡还是校友

作者:徐麟,某互联网公司数据分析狮,个人公众号数据森麟(id:shujusenlin)前言 互联网作为一个快速发展的新兴领域,聚集了大量的优秀人才,前沿技术的广泛应用也不断地为互联网注入着新的活力。能

东南亚的博彩骗局,被房贷压垮的中国程序员,一个褪色的互联网黄金时代

当大国经济在经历互联网寒冬——程序员失业、就业承压时,一场魔幻的骗局正在东南亚加速发酵。这是一场针对中国程序员、针对走投无路的底层群众的骗局。利益链上的每个人都赚得盆满钵满,而榨取的,恰恰都是同胞的血

中国互联网公司亏损能力排行榜

作者 |  挖数来源| 挖数(ID:washu66)很多互联网公司整天吹自己市值多高,用户数有多少,实际上是亏损的,而另外有些公司市值并不高,但实际上非常赚钱。挖数这几天收集了包括A股、港股和美股共计

RTSP、RTMP网络摄像头互联网无插件直播视频流媒体服务器EasyNVR在windows上无法启动问题排查

背景需求随着雪亮工程、明厨亮灶、手机看店、智慧幼儿园监控等行业开始将传统的安防摄像头进行互联网、微信直播,我们知道摄像头直播的春天了。将安防摄像头或NVR上的视频流转成互联网直播常用的RTSP、RTM

一个大型互联网公司后台基础设施发展简史

笔者在某大厂后台从事后台研发工作多年,亲历了后台基础设施随着业务的发展一步步演进,如果代码也有生命,整个过程堪称一部精彩的进化史。下面通过一张时间轴思维导图将整个过程呈现出来,后续将不定期分享其中的专

互联网行业如何防御CC攻击?

如今,互联网给企业生活带来了各种各样便利的同时,也给企业带来了各种网络风险。尤其是互联网行业,一直是DDoS、CC等攻击的重灾区,所以,做好攻击防御非常必要。但仍有一些互联网企业不重视安全防御,认为不

万字详解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