高并发系统的通用设计方法是什么？

归纳起来共有三种方法。

• Scale-out（横向扩展）：分而治之是一种常见的高并发系统设计方法，采用分布式部署的方式把流量分流开，让每个服务器都承担一部分并发和流量。

• 缓存：使用缓存来提高系统的性能。

• 异步：在某些场景下，未处理完成之前我们可以让请求先返回，在数据准备好之后再通知请求方，这样可以在单位时间内处理更多的请求。

Scale-up vs Scale-out

那么什么时候选择 Scale-up（纵向扩展），什么时候选择 Scale-out（横向扩展呢？

一般来讲，在我们系统设计初期会考虑使用 Scale-up 的方式，因为这种方案足够简单，所谓能用堆砌硬件解决的问题就用硬件来解决，但是当系统并发超过了单机的极限时，我们就要使用 Scale-out 的方式。

Scale-out 虽然能够突破单机的限制，但也会引入一些复杂问题。比如，如果某个节点出现故障如何保证整体可用性？当多个节点有状态需要同步时如何保证状态信息在不同节点的一致性？如何做到使用方无感知的增加和删除节点？

使用缓存提升性能

缓存遍布在系统设计的每个角落，从操作系统到浏览器，从数据库到消息队列，任何略微复杂的服务和组件中你都可以看到缓存的影子。我们使用缓存的主要作用是提升系统的访问性能，在高并发的场景下就可以支撑更多用户的同时访问。

异步处理

那么什么是同步，什么是异步呢？

以方法调用为例，同步调用代表调用方要阻塞等待被调用方法中的逻辑执行完成。这种方式下，当被调用方法响应时间较长时，会造成调用方长久的阻塞，在高并发下会造成整体系统性能下降甚至发生雪崩。

异步调用恰恰相反，调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑，在被调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。

既然我们了解了这三种方法，那么是不是意味着在高并发系统设计中，开发一个系统时要把这些方法都用上呢？

当然不是，系统的设计是不断演进的。不同量级的系统有不同的痛点，也就有不同的架构设计的侧重点。如果都按照百万、千万并发来设计系统，那么这些系统的命运一定是灭亡。盲目地追从只能让我们的架构复杂不堪，最终难以维护。

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

所以我建议一般系统的演进过程应该遵循下面的思路：

• 最简单的系统设计满足业务需求和流量现状，选择最熟悉的技术体系。

• 随着流量的增加和业务的变化修正架构中存在问题的点，如单点问题、横向扩展问题、性能无法满足需求的组件。在这个过程中，选择社区成熟的、团队熟悉的组件帮助我们解决问题，在社区没有合适解决方案的前提下才会自己造轮子。

• 当对架构的小修小补无法满足需求时，考虑重构、重写等大的调整方式以解决现有的问题。

归根结底一句话：高并发系统的演进应该是循序渐进，以解决系统中存在的问题为目的。