架构师教你如何设计一个高并发系统?大多程序员都收藏了

时间: 2019-07-31阅读: 314标签: 架构

面试剖析

其实所谓的高并发,如果你要理解这个问题呢,其实就得从高并发的根源出发,为啥会有高并发?为啥高并发就很牛逼?

我说的浅显一点,很简单,就是因为刚开始系统都是连接数据库的,但是要知道数据库支撑到每秒并发两三千的时候,基本就快完了。所以才有说,很多公司,刚开始干的时候,技术比较 low,结果业务发展太快,有的时候系统扛不住压力就挂了。

当然会挂了,凭什么不挂?你数据库如果瞬间承载每秒 5000/8000,甚至上万的并发,一定会宕机,因为比如 mysql 就压根儿扛不住这么高的并发量。

所以为啥高并发牛逼?就是因为现在用互联网的人越来越多,很多 app、网站、系统承载的都是高并发请求,可能高峰期每秒并发量几千,很正常的。如果是什么双十一之类的,每秒并发几万几十万都有可能。

那么如此之高的并发量,加上原本就如此之复杂的业务,咋玩儿?真正厉害的,一定是在复杂业务系统里玩儿过高并发架构的人,但是你没有,那么我给你说一下你该怎么回答这个问题:

可以分为以下 6 点:

1.系统拆分
2.缓存
3.MQ
4. 分库分表
5.读写分离
6.ElasticSearch


系统拆分

将一个系统拆分为多个子系统,用 dubbo 来搞。然后每个系统连一个数据库,这样本来就一个库,现在多个数据库,不也可以扛高并发么。


缓存

缓存,必须得用缓存。大部分的高并发场景,都是**读多写少**,那你完全可以在数据库和缓存里都写一份,然后读的时候大量走缓存不就得了。毕竟人家 redis 轻轻松松单机几万的并发。所以你可以考虑考虑你的项目里,那些承载主要请求的**读场景,怎么用缓存来抗高并发。


MQ

MQ,必须得用 MQ。可能你还是会出现高并发写的场景,比如说一个业务操作里要频繁搞数据库几十次,增删改增删改,疯了。那高并发绝对搞挂你的系统,你要是用 redis 来承载写那肯定不行,人家是缓存,数据随时就被 LRU 了,数据格式还无比简单,没有事务支持。所以该用 mysql 还得用 mysql 啊。那你咋办?用 MQ 吧,大量的写请求灌入 MQ 里,排队慢慢玩儿,后边系统消费后慢慢写,控制在 mysql 承载范围之内。所以你得考虑考虑你的项目里,那些承载复杂写业务逻辑的场景里,如何用 MQ 来异步写,提升并发性。MQ 单机抗几万并发也是 ok 的,这个之前还特意说过。


分库分表

分库分表,可能到了最后数据库层面还是免不了抗高并发的要求,好吧,那么就将一个数据库拆分为多个库,多个库来扛更高的并发;然后将一个表**拆分为多个表**,每个表的数据量保持少一点,提高 sql 跑的性能。


读写分离

读写分离,这个就是说大部分时候数据库可能也是读多写少,没必要所有请求都集中在一个库上吧,可以搞个主从架构,主库写入,从库读取,搞一个读写分离。读流量太多的时候,还可以加更多的从库。


ElasticSearch

Elasticsearch,简称 es。es 是分布式的,可以随便扩容,分布式天然就可以支撑高并发,因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作,可以考虑用 es 来承载,还有一些全文搜索类的操作,也可以考虑用 es 来承载。

上面的 6 点,基本就是高并发系统肯定要干的一些事儿,大家可以仔细结合之前讲过的知识考虑一下,到时候你可以系统的把这块阐述一下,然后每个部分要注意哪些问题,之前都讲过了,你都可以阐述阐述,表明你对这块是有点积累的。

其实大部分公司,真正看重的,不是说你掌握高并发相关的一些基本的架构知识,架构中的一些技术,RocketMQ、Kafka、Redis、Elasticsearch,高并发这一块,你了解了,也只能是次一等的人才。对一个有几十万行代码的复杂的分布式系统,一步一步架构、设计以及实践过高并发架构的人,这个经验是难能可贵的。



吐血推荐

1.站长广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入...

2.休闲娱乐: 直播/交友    优惠券领取   网页游戏   H5游戏

链接: http://www.fly63.com/article/detial/4436

软件架构师之路

软件架构师是一名软件开发专家,他可以进行高层设计选择并决定技术标准,包括软件编码标准,工具和平台。软件架构可以被抽象的分为几个层次,不同的层次对技能的要求不同。对层次有很多不同的划分

前端领域不需要架构师?

在传统桌面软件开发中,架构师是一种通过设计架构保证团队能够良好分工和有序工作的岗位。在工程领域,我们凡是要做点什么事儿,都会有明确的目的性,这个目的性,一定是为了完成生产服务业务的。

实用的软件架构方法

软件架构就是软件的基本结构,它是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。

微前端架构:如何由内而外取代单体架构

如何利用微前端技术实现单体应用程序的现代化改造?在本篇教程中,我们将探讨如何将前端从单体架构当中剥离出来,并快速完成微前端架构迁移。本文作者将结合个人项目实践经验为大家介绍心得。

微服务架构陷阱:过渡设计和设计不足

在这篇文章里,我将简要地介绍在设计微服务架构时需要注意的问题。如果实施得当,就会获得自治能力和灵活性,但同时也会带来通信延迟和部署及托管成本。这篇文章并不是一个高级指南

网站架构优化性能

最初业务量不大,访问量小,此时的架构,应用程序、数据库、文件都部署在一台服务器上,有些甚至仅仅是租用主机空间, 将应用程序、数据库、文件各自部署在独立的服务器上

成为一个优秀架构师,你必须了解的 30 条设计原则

众所周知,架构师的角色,更偏向于策划、而非指挥,塑造、而非支配,其存在的意义,在于引导大家讨论、而非自己主宰一切。但是,具体应该如何执行呢?本文作者整理了 30 个公认的架构原则

创建软件架构时应该关注什么?

软件架构师的首要关注点不是系统的功能,而是软件的品质,软件品质关注点指明了功能呢必须以何种方式交付,才能被系统的利益相关人所接受。作为一个架构师,你应该了解软件产品利益人以及他们的关注点:

基于 NodeJS 的 serverless 架构实践

通过将 BFF 构建于 serverless 之上,将人工智能实验室(天猫精灵)数十个中后台应用整合到了一个统一入口。用云函数的方式取代了传统基于 NodeJS 的 BFF 层,提供了在一个站点下不同应用以及不同环境的快速切换能力

软件架构被高估,清晰简单的设计被低估

软件架构最佳实践、企业架构模式以及系统描述的正式方法都是非常重要且实用的工具,总会有合适的场景让它们发挥作用。但在设计系统时,请从简单始、以简单终,尽可能避免一切会无谓提高复杂度的架构与正式工具

fly63.com版权所有,内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权,请与小编联系!情况属实本人将予以删除!

文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全