目录
- 一、一道面试题的背景引入
- 二、先考虑一个最简单的系统架构
- 三、系统集群化部署
- 四、数据库分库分表 + 读写分离
- 五、缓存集群引入
- 六、引入消息中间件集群
- 七、现在能hold住高并发面试题了吗
- 八、本文能带给你什么启发?
一、的背景引入
这篇文章,我们聊聊大量同学问我的一个问题,面试的时候被问到一个让人特别手足无措的问题:你的系统如何支撑高并发?
大多数同学被问到这个问题压根儿没什么思路去回答,不知道从什么地方说起,其实本质就是没经历过一些真正有高并发系统的锤炼罢了。
因为没有过相关的项目经历,所以就没法从真实的自身体会和经验中提炼出一套回答,然后系统的阐述出来自己复杂过的系统如何支撑高并发的。
所以,这篇文章就从这个角度切入来简单说说这个问题,用一个最简单的思路来回答,大致如何应对。
当然这里首先说清楚一个前提:高并发系统各不相同。比如每秒百万并发的中间件系统、每日百亿请求的网关系统、瞬时每秒几十万请求的秒杀大促系统。
他们在应对高并发的时候,因为系统各自自身特点的不同,所以应对架构都是不一样的。
另外,比如电商平台中的订单系统、商品系统、库存系统,在高并发场景下的架构设计也是不同的,因为背后的业务场景什么的都不一样。
所以,这篇文章主要是给大家提供一个回答这类问题的思路,不涉及任何复杂架构设计,让你不至于在面试中被问到这个问题时,跟面试官大眼瞪小眼。
具体要真能在面试的时候回答好这个问题,建议各位参考一下本文思路,然后对你自己手头负责的系统多去思考一下,最好做一些相关的架构实践。
二、先考虑一个最简单的系统架构
假设刚刚开始你的系统就部署在一台机器上,背后就连接了一台数据库,数据库部署在一台服务器上。
我们甚至可以再现实点,给个例子,你的系统部署的机器是4核8G,数据库服务器是16核32G。
此时假设你的系统用户量总共就10万,用户量很少,日活用户按照不同系统的场景有区别,我们取一个较为客观的比例,10%吧,每天活跃的用户就1万。
按照28法则,每天高峰期算他4个小时,高峰期活跃的用户占比达到80%,就是8000人活跃在4小时内。
然后每个人对你的系统发起的请求,我们算他每天是20次吧。那么高峰期8000人发起的请求也才16万次,平均到4小时内的每秒(14400秒),每秒也就10次请求。
好吧!完全跟高并发搭不上边,对不对?
然后系统层面每秒是10次请求,对数据库的调用每次请求都会好几次数据库操作的,比如做做crud之类的。
那么我们取一个一次请求对应3次数据库请求吧,那这样的话,数据库层每秒也就30次请求,对不对?
按照这台数据库服务器的配置,支撑是绝对没问题的。
上述描述的系统,用一张图表示,就是下面这样:
三、系统集群化部署
假设此时你的用户数开始快速增长,比如注册用户量增长了50倍,上升到了500万。
此时日活用户是50万,高峰期对系统每秒请求是500/s。然后对数据库的每秒请求数量是1500/s,这个时