高并发代表着高流量，高并发系统的魅力就在于我们可以凭借自己的聪明才智设计巧妙的方案，从而抵抗住流量的

冲击，带给用户更好的使用体验，让流量可以平稳的被系统中的服务或组件平稳的处理。

而我们在应对高并发大流量时也会采用类似“抵御洪水”的方案，归纳起来共有三种方法。

• Scale-out(横向扩展) ：分而治之是一种常见的高并发处理方式，采用分布式部署的方式把流量分开，让每个服务器承担一部分并发流量
• 缓存 ：使用缓存来提高系统系统，就好比用“扩宽河道”的方式来抵抗高并发大流量的冲击。
• 异步：在某些场景下，未处理完成之前，我们可以让请求先返回，在数据准备好之后，再通知请求方，这样在单位时间可以处理更多请求（处理请求线程数量一定情况下）

异步调用在高并发大流量系统中被大量使用，比如我们熟悉的12306网站。当我们订票时，页面会显示系统正在排队，这个提示代表着系统在异步处理我们的订票请求，在12306系统中查询余票、下单和更改余票状态都是比较耗时的操作，可能涉及多个内部系统中间的调用，如果是同步调用就会像12306初期上线那样，高峰期永远不可能下单成功。

而采用异步的方式，后端处理时会把请求丢到队列里，同时快速响应用户，告诉用户正在排队处理，然后释放出来资源处理更多的请求。

订票处理完之后，再通知用户订票成功或者失败。

处理逻辑后移到异步处理程序中，web服务的压力减小了，资源占用少了。自然就能接受更多的用户订票请求，系统承受高并发的能力也就提升了。

既然我们理解了这三种方法，那是不是意味着我们开发一个高并发系统时候，这三种方法都用上呢？

当然不是，系统的设计是不断演进的。

罗马不是一天建成的，系统的设计也是如此。不同量级的系统有不同的痛点，也就有不同的架构设计侧重点。如果按照百万、千万标准来设计系统，电商一律向淘宝看起，IM一律向微信、QQ看齐，那这些系统的命运就是走向灭亡。

我之前也踩过一些坑，参与过一个创业项目，在初始阶段就采用微服务架构。但由于当时人力有限，团队技术积累不足，因此在实际项目开发中，发现无法驾驭如此复杂的架构，出现问题难以定位，系统整体性能下降等多方面问题。最后不得不回归到单体的架构中。

所以我的建议：

• 满足业务需求和流量现状，选择最简单的系统设计和技术体系
• 随着业务的增加和流量的变化，逐步修正系统中存在的问题，比如单点问题、横向扩展问题、有瓶颈的组件等，尽量选择有开源社区支持的组件，社区实在没有的再自己造轮子。
• 当对架构的小修小补无法满足需求时，考虑重构、重写等以解决现有问题

以淘宝为例，当时在业务从 0 到 1 的阶段是通过购买的方式快速搭建了系统。而后，随着流量的增长，淘宝做了一系列的技术改造来提升高并发处理能力，比如数据库存储引擎从 MyISAM 迁移到 InnoDB，数据库做分库分表，增加缓存，启动中间件研发等。

当这些都无法满足时，就考虑整体架构的大规模重构，比如著名的五彩石”项目让淘宝的架构从单体演进为服务化架构。 正是通过逐步的技术演进，淘宝才进化出如今承担过亿 QPS 的技术架构。

总结

归根结底一句话：高并发系统的演进应该是循序渐进的，以解决实际业务中问题为驱动力。

本节主要介绍三种高并发系统的设计思路：scale-out（横向扩展）、缓存、异步

至于具体采取哪一种方式，还是全部采用还要根据你自己的系统来考量。

高并发系统是一个渐进的过程，并非一蹴而就。

martin fowler 说过，能用单体解决的问题，就不用分布式。不能为了技术而技术，采用分布式固然可以分流用户请求，提高系统的响应能力，但同样也带来了复杂性。如果单体能解决的问题，就不要想着诗和远方，因为系统内部进程间的调用，肯定比不同物理机的进程之间调用的更快。

高并发除了横向扩容，缓存和异步化，系统还要做好保护，比如限流降级，过载保护。