每个行业都一样，人才都是分层次的，从事技术行业的程序员们更是如此，按照技术能力分为三六九等。

每个层次的人出去面试，面试官考察的方向是不一样的。

刚入职场的小白，会问你很多基础性的知识，有过几年经验的程序员，会问你相关的项目经历、架构设计。如果是行业有影响力的技术专家，不一定会问你技术，可能就跟你聊聊行业动态、技术发展趋势。

如果你出去面试，面试官问你，如何设计一个高并发的系统？

那么你就得好好回答了，为什么？

如果你确实在互联网公司干过高并发系统，经历过每天几亿几十亿的流量，高峰期每秒几万甚至几十万的并发的话，面试官肯定不会问你如何设计一个高并发系统。而是会让你介绍下你们的项目，你们项目架构是什么样的？怎么部署的？部署了多少台机器？缓存怎么用的？数据库怎么用的？就是深挖细节，你到底是如何抗下高并发的。

如果面试官问你如何设计一个高并发系统，一定是你没实际干过高并发系统。面试官看你简历没什么亮点，又有几年工作经验，所以给你一个开放式的设计题，通过这个题目，了解你虽然没有实际干过高并发系统，但有没有自己研究学习过，有没有相关的知识积累。

面试官当然是希望招个真正干过高并发的人了，但这种人很难招，所以只能退而求其次，招一个没有实际经验但有相关知识积累的人。

所以此时，你必须展示出你所有关于高并发的知识了！

这种问题呢，最好不要一上来就给出最终的一套完备的高并发系统架构，而是不断地演进，正常的系统架构升级也是这么个过程。

比如，最开始时每秒最多10个请求，一个单体系统就可以抗住。

图1 单体系统

接下来10w个用户变成100w，1000w个用户，每秒1000个请求，你线上机器内存开始开始感觉到紧张，使用率开始上升，cup使用率飙升。你数据库可能就扛不住了，因为数据库磁盘io效率开始下降，很多SQL变得很慢。

这个时候你要干的第一件事情就是系统拆分，把之前的单体系统拆分成多个系统，数据库也跟随系统做拆分，每个系统使用自己的数据库。

图2 系统拆分

单体系统拆分成立3个系统，每个系统访问自己独立的数据库，每个数据库部署在独立的机器上。原来一个数据库最多可以抗1000的并发，现在所有的资源翻了三倍，可以抗3000的并发。

假设现在系统每秒又3000个请求了，你系统可能又快扛不住了，这时候你怎么办呢？用缓存。

redis缓存可以轻松的抗几万的并发，用缓存后呢，大量的读请求可以走缓存，很多系统都是读多写少，比如资讯系统，3000个并发请求，缓存至少拦截掉2000个读请求，剩下1000个写请求走数据库。

图3 增加缓存

假设现在用户增长到1亿用户，每秒钟1w请求，写请求达到2000个，数据库又扛不住了，怎么办呢，可以在数据库前面加个MQ。

图4 增加MQ

这里MQ主要起到削峰的作用，高峰期大量的写请求积压在MQ中，等高峰期过了，再慢慢消费。

接下来用户增长到2亿，每秒2w个请求，4000个写请求。MQ就会积压非常多的消息，导致很多数据很久都不能被修改掉，这是用户不能忍受的。

单库写已经达到瓶颈了，怎么办，分库分表啊。你可以把一台数据库拆分为3台数据库，用多个数据库分摊写请求压力。

图5 分库分表

缓存有过期的可能，如果请求访问的时候，缓存刚好过期了，就会导致读请求直接穿透到数据库里，所以你还可以给数据库加上读写分离，让读请求分流到从库去，降低对主库的压力。

图6 读写分离

针对搜索的话，数据量小的时候，可以走数据库，当数据量大了后，可以把相关的数据抽出来放到es集群里，es集群专门提供查询服务。

es集群是分布式的，可以放几十亿的数据，可以针对系统的数据量和搜索并发，配置合适数量的机器。

图7 es搜索

总之，就是随着用户量和并发量的不断增长，系统的架构也在不断地演进。上面这种架构演进还是比较简单的，真正复杂业务系统里，并不是简单的堆一些高大上的技术或框架，其系统远远比上面的系统复杂几十倍。

如果面试的时候，面试官问你如何设计一个高并发系统，你可以按照上面这个思路回答。虽然你可能没经历过高并发系统，但本文如果能让大家对这个问题多一些思考，在面试的时候，有一些系统性的思路和阐述，那么也就达到本文的目的了。