面试最让你手足无措的一个问题：你的系统如何支撑高并发？【石杉的架构笔记】

时间 2019-11-06

标签面试让你手足无措一个问题系统如何支撑并发石杉的架构笔记栏目快乐工作繁體版

原文原文链接

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）程序员

周一至周五早8点半！精品技术文章准时送上！面试

（1）一道面试题的背景引入

这篇文章，咱们聊聊大量同窗问个人一个问题，面试的时候被问到一个让人特别手足无措的问题：你的系统如何支撑高并发？

大多数同窗被问到这个问题压根儿没什么思路去回答，不知道从什么地方提及，其实本质就是没经历过一些真正有高并发系统的锤炼罢了。

由于没有过相关的项目经历，因此就无法从真实的自身体会和经验中提炼出一套回答，而后系统的阐述出来本身复杂过的系统如何支撑高并发的。

因此，这篇文章就从这个角度切入来简单说说这个问题，用一个最简单的思路来回答，大体如何应对。

固然这里首先说清楚一个前提：高并发系统各不相同。好比每秒百万并发的中间件系统、每日百亿请求的网关系统、瞬时每秒几十万请求的秒杀大促系统。

他们在应对高并发的时候，由于系统各自自身特色的不一样，因此应对架构都是不同的。

另外，好比电商平台中的订单系统、商品系统、库存系统，在高并发场景下的架构设计也是不一样的，由于背后的业务场景什么的都不同。

因此，这篇文章主要是给你们提供一个回答这类问题的思路，不涉及任何复杂架构设计，让你不至于在面试中被问到这个问题时，跟面试官大眼瞪小眼。

具体要真能在面试的时候回答好这个问题，建议各位参考一下本文思路，而后对你本身手头负责的系统多去思考一下，最好作一些相关的架构实践。

（2）先考虑一个最简单的系统架构

假设刚刚开始你的系统就部署在一台机器上，背后就链接了一台数据库，数据库部署在一台服务器上。

咱们甚至能够再现实点，给个例子，你的系统部署的机器是4核8G，数据库服务器是16核32G。

此时假设你的系统用户量总共就10万，用户量不多，日活用户按照不一样系统的场景有区别，咱们取一个较为客观的比例，10%吧，天天活跃的用户就1万。

按照28法则，天天高峰期算他4个小时，高峰期活跃的用户占比达到80%，就是8000人活跃在4小时内。

而后每一个人对你的系统发起的请求，咱们算他天天是20次吧。那么高峰期8000人发起的请求也才16万次，平均到4小时内的每秒（14400秒），每秒也就10次请求。

好吧！彻底跟高并发搭不上边，对不对？

而后系统层面每秒是10次请求，对数据库的调用每次请求都会好几回数据库操做的，好比作作crud之类的。

那么咱们取一个一次请求对应3次数据库请求吧，那这样的话，数据库层每秒也就30次请求，对不对？

按照这台数据库服务器的配置，支撑是绝对没问题的。

上述描述的系统，用一张图表示，就是下面这样：

（3）系统集群化部署

假设此时你的用户数开始快速增加，好比注册用户量增加了50倍，上升到了500万。

此时日活用户是50万，高峰期对系统每秒请求是500/s。而后对数据库的每秒请求数量是1500/s，这个时候会怎么样呢？

按照上述的机器配置来讲，若是你的系统内处理的是较为复杂的一些业务逻辑，是那种重业务逻辑的系统的话，是比较耗费CPU的。

此时，4核8G的机器每秒请求达到500/s的时候，极可能你会发现你的机器CPU负载较高了。

而后数据库层面，以上述的配置而言，其实基本上1500/s的高峰请求压力的话，还算能够接受。

这个主要是要观察数据库所在机器的磁盘负载、网络负载、CPU负载、内存负载，按照咱们的线上经验而言，那个配置的数据库在1500/s请求压力下是没问题的。

因此此时你须要作的一个事情，首先就是要支持你的系统集群化部署。

你能够在前面挂一个负载均衡层，把请求均匀打到系统层面，让系统能够用多台机器集群化支撑更高的并发压力。

好比说这里假设给系统增长部署一台机器，那么每台机器就只有250/s的请求了。

这样一来，两台机器的CPU负载都会明显下降，这个初步的“高并发”不就先cover住了吗？

要是连这个都不作，那单台机器负载愈来愈高的时候，极端状况下是可能出现机器上部署的系统没法有足够的资源响应请求了，而后出现请求卡死，甚至系统宕机之类的问题。

因此，简单小结，第一步要作的：

添加负载均衡层，将请求均匀打到系统层。系统层采用集群化部署多台机器，扛住初步的并发压力。

此时的架构图变成下面的样子：

（4）数据库分库分表 + 读写分离

假设此时用户量继续增加，达到了1000万注册用户，而后天天日活用户是100万。

那么此时对系统层面的请求量会达到每秒1000/s，系统层面，你能够继续经过集群化的方式来扩容，反正前面的负载均衡层会均匀分散流量过去的。

可是，这时数据库层面接受的请求量会达到3000/s，这个就有点问题了。

此时数据库层面的并发请求翻了一倍，你必定会发现线上的数据库负载愈来愈高。

每次到了高峰期，磁盘IO、网络IO、内存消耗、CPU负载的压力都会很高，你们很担忧数据库服务器可否抗住。

没错，通常来讲，对那种普通配置的线上数据库，建议就是读写并发加起来，按照上述咱们举例的那个配置，不要超过3000/s。

由于数据库压力过大，首先一个问题就是高峰期系统性能可能会下降，由于数据库负载太高对性能会有影响。

另一个，压力过大把你的数据库给搞挂了怎么办？

因此此时你必须得对系统作分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这是做为主库承载写入请求的。

而后每一个主库都挂载至少一个从库，由从库来承载读请求。

此时假设对数据库层面的读写并发是3000/s，其中写并发占到了1000/s，读并发占到了2000/s。

那么一旦分库分表以后，采用两台数据库服务器上部署主库来支撑写请求，每台服务器承载的写并发就是500/s。每台主库挂载一个服务器部署从库，那么2个从库每一个从库支撑的读并发就是1000/s。

简单总结，并发量继续增加时，咱们就须要focus在数据库层面：分库分表、读写分离。

此时的架构图以下所示：

（5）缓存集群引入

接着就好办了，若是你的注册用户量愈来愈大，此时你能够不停的加机器，好比说系统层面不停加机器，就能够承载更高的并发请求。

而后数据库层面若是写入并发愈来愈高，就扩容加数据库服务器，经过分库分表是能够支持扩容机器的，若是数据库层面的读并发愈来愈高，就扩容加更多的从库。

可是这里有一个很大的问题：数据库其实自己不是用来承载高并发请求的，因此一般来讲，数据库单机每秒承载的并发就在几千的数量级，并且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。

若是你就是简单的不停的加机器，实际上是不对的。

因此在高并发架构里一般都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。

因此单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。

因此你彻底能够根据系统的业务特性，对那种写少读多的请求，引入缓存集群。

具体来讲，就是在写数据库的时候同时写一份数据到缓存集群里，而后用缓存集群来承载大部分的读请求。

这样的话，经过缓存集群，就能够用更少的机器资源承载更高的并发。

好比说上面那个图里，读请求目前是每秒2000/s，两个从库各自抗了1000/s读请求，可是其中可能每秒1800次的读请求都是能够直接读缓存里的不怎么变化的数据的。

那么此时你一旦引入缓存集群，就能够抗下来这1800/s读请求，落到数据库层面的读请求就200/s。

一样，给你们来一张架构图，一块儿来感觉一下：

按照上述架构，他的好处是什么呢？

可能将来你的系统读请求每秒都几万次了，可是可能80%~90%都是经过缓存集群来读的，而缓存集群里的机器可能单机每秒均可以支撑几万读请求，因此耗费机器资源不多，可能就两三台机器就够了。

你要是换成是数据库来试一下，可能就要不停的加从库到10台、20台机器才能抗住每秒几万的读并发，那个成本是极高的。

好了，咱们再来简单小结，承载高并发须要考虑的第三个点：

不要盲目进行数据库扩容，数据库服务器成本昂贵，且自己就不是用来承载高并发的针对写少读多的请求，引入缓存集群，用缓存集群抗住大量的读请求

（6）引入消息中间件集群

接着再来看看数据库写这块的压力，实际上是跟读相似的。

假如说你全部写请求所有都落地数据库的主库层，固然是没问题的，可是写压力要是愈来愈大了呢？

好比每秒要写几万条数据，此时难道也是不停的给主库加机器吗？

能够固然也能够，可是同理，你耗费的机器资源是很大的，这个就是数据库系统的特色所决定的。

相同的资源下，数据库系统过重太复杂，因此并发承载能力就在几千/s的量级，因此此时你须要引入别的一些技术。

好比说消息中间件技术，也就是MQ集群，他是很是好的作写请求异步化处理，实现削峰填谷的效果。

假如说，你如今每秒是1000/s次写请求，其中好比500次请求是必须请求过来立马写入数据库中的，可是另外500次写请求是能够容许异步化等待个几十秒，甚至几分钟后才落入数据库内的。

那么此时你彻底能够引入消息中间件集群，把容许异步化的每秒500次请求写入MQ，而后基于MQ作一个削峰填谷。好比就以平稳的100/s的速度消费出来而后落入数据库中便可，此时就会大幅度下降数据库的写入压力。

ps：关于MQ削峰填谷的概念，在公众号以前讲消息中间件的文章中已详细阐述，若是大伙儿忘记了，能够回顾一下。

此时，架构图变成了下面这样：

你们看上面的架构图，首先消息中间件系统自己也是为高并发而生，因此一般单机都是支撑几万甚至十万级的并发请求的。

因此，他自己也跟缓存系统同样，能够用不多的资源支撑很高的并发请求，用他来支撑部分容许异步化的高并发写入是没问题的，比使用数据库直接支撑那部分高并发请求要减小不少的机器使用量。

并且通过消息中间件的削峰填谷以后，好比就用稳定的100/s的速度写数据库，那么数据库层面接收的写请求压力，不就成了500/s + 100/s = 600/s了么？

你们看看，是否是发现减轻了数据库的压力？

到目前为止，经过下面的手段，咱们已经可让系统架构尽量用最小的机器资源抗住了最大的请求压力，减轻了数据库的负担。

系统集群化数据库层面的分库分表+读写分离针对读多写少的请求，引入缓存集群针对高写入的压力，引入消息中间件集群，

初步来讲，简单的一个高并发系统的阐述是说完了。

可是，其实故事到这里还远远没有结束。

（7）如今能hold住高并发面试题了吗？

看完了这篇文章，你以为本身能回答好面试里的高并发问题了吗？

很遗憾，答案是不能。并且我以为单单凭借几篇文章是绝对不可能真的让你彻底回答好这个问题的，这里有不少缘由在里面。

首先，高并发这个话题自己是很是复杂的，远远不是一些文章能够说的清楚的，他的本质就在于，真实的支撑复杂业务场景的高并发系统架构实际上是很是复杂的。

好比说每秒百万并发的中间件系统、每日百亿请求的网关系统、瞬时每秒几十万请求的秒杀大促系统、支撑几亿用户的大规模高并发电商平台架构，等等。

为了支撑高并发请求，在系统架构的设计时，会结合具体的业务场景和特色，设计出各类复杂的架构，这须要大量底层技术支撑，须要精妙的架构和机制设计的能力。

最终，各类复杂系统呈现出来的架构复杂度会远远超出大部分没接触过的同窗的想象。

若是你们想要看一下有必定发复杂度的系统的架构设计和演进过程，能够看一下以前写的一个系列专栏《亿级流量系统架构演进》。

可是那么复杂的系统架构，经过一些文章是很难说的清楚里面的各类细节以及落地生产的过程的。

其次，高并发这话题自己包含的内容也远远不止本文说的这么几个topic：分库分表、缓存、消息。

一个完整而复杂的高并发系统架构中，必定会包含各类复杂的自研基础架构系统、各类精妙的架构设计（好比热点缓存架构设计、多优先级高吞吐MQ架构设计、系统全链路并发性能优化设计，等等）、还有各类复杂系统组合而成的高并发架构总体技术方案、还有NoSQL（Elasticsearch等）/负载均衡/Web服务器等相关技术。

因此你们切记要对技术保持敬畏之心，这些东西都很难经过一些文章来表述清楚。

最后，真正在生产落地的时候，高并发场景下你的系统会出现大量的技术问题。

好比说消息中间件吞吐量上不去须要优化、磁盘写压力过大性能太差、内存消耗过大容易撑爆、分库分表中间件不知道为何丢了数据，等等吧。

诸如此类的问题很是多，这些也不可能经过文章给所有说清楚。

（8）本文能带给你什么启发？

其实本文的定位，就是对高并发这个面试topic作一个扫盲，由于我发现大部分来问我这个问题的同窗，连本文阐述的最最基本的高并发架构演进思路可能都没理解。

固然，也是由于毕竟没真的作太高并发系统，没相关经验，确实很难理解好这个问题。

因此本文就是让不少没接触过的同窗有一个初步的感知，这个高并发究竟是怎么回事儿，到底对系统哪里有压力，要在系统架构里引入什么东西，才能够比较好的支撑住较高的并发压力。

并且你能够顺着本文的思路继续思考下去，结合你本身熟悉和知道的一些技术继续思考。

好比说，你熟悉Elasticsearch技术，那么你就能够思考，唉？在高并发的架构之下，是否是能够经过分布式架构的ES技术支撑高并发的搜索？

上面所说，权当抛砖引玉。你们本身平时必定要多思考，本身多画图，盘点盘点本身手头系统的请求压力。计算一下分散到各个中间件层面的请求压力，到底应该如何利用最少的机器资源最好的支撑更高的并发请求。

这才是一个好的高并发架构设计思路。

若是起到这个效果，本文就成功了。剩下的，仍是建议各位同窗，对高并发这个话题，结合本身手头负责的系统多作思考。

好比当前业务场景下，你的系统有多大的请求压力？若是请求压力增加10倍你的架构如何支撑？若是请求压力增加100倍，你的架构如何支撑？若是请求压力增加1000倍，你的架构如何支撑？

平时必定多给本身设置一些技术挑战，敦促本身去思考本身的系统，最好多作写架构上的演练、落地和实践，本身实际操做一下，才有更好的感知。

而后在面试的时候，起码本身作过必定深度的思考，结合本身负责的系统作过一些实践，能够跟面试官有一个较为清晰和系统的阐述。

虽然大部分同窗可能没机会经历那种真正大规模超高并发的系统架构的设计，可是本文若是能让你们平时对本身的项目多一些思考。在面试的时候，有一些系统性的思路和阐述，那么也就达到本文的目的了。

END

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授