国庆专栏-高并发系统：它的通用设计方法是什么？

高并发系统设计类似于治理大规模水流问题，我们需要巧妙的方案来抵抗巨大的流量，提供更好的用户体验。这些方案可以看作是操纵流量，使其更平稳地被系统处理，就像古代治水方式一样。

拓宽河道（Scale-out，横向扩展）：这是常见的方法，类似于古代大禹拓宽河道，通过分布式部署将流量分散到多个服务器上，每个服务器处理一部分并发和流量，以降低单个服务器的负载。
利用缓存：就像清除淤沙来使水流更畅顺一样，我们可以使用缓存来提高系统性能。缓存可以存储已经处理过的数据，以减轻数据库或其他服务的压力，从而更有效地处理请求。
采用异步处理：有时候，我们可以让请求先返回，而不必等待处理完成。类似于将水储存在水库中，然后缓慢释放水来提高下游的抗洪能力。在某些场景下，未处理完成的请求可以在后台处理，然后通知请求方，这样可以在单位时间内处理更多的请求。

Scale-out（横向扩展）。

在高并发系统设计中，Scale-out 是一项重要的策略，类似于计算机硬件性能的发展历程，其中涉及到摩尔定律的概念。

摩尔定律是由Intel创始人之一戈登·摩尔在1965年提出的。它指出，集成电路上可以容纳的晶体管数量每隔大约两年就会增加一倍。后来，Intel的首席执行官大卫·豪斯提出了“18个月”的说法，即预计每18个月将芯片的性能提升一倍，这一说法广泛传播开来。尽管摩尔定律最初描述的是芯片的发展速度，但我们可以将其扩展为整个硬件性能的提升。自20世纪后半叶以来，计算机硬件性能一直以指数级别的速度发展。即使在今天，摩尔定律仍然有一定影响，尽管近年来存在一些挑战。

有专家预测，未来摩尔定律可能不再适用，因为目前的芯片技术已经达到了5纳米级别，进一步的缩小空间有限，难以继续按照摩尔定律的速度提高性能。在这个背景下，多核技术应运而生，它通过将多个CPU核心集成在一个芯片上，大幅提高了CPU的并行处理能力。这种技术使得系统可以同时处理多个任务，从而应对高并发的需求。

Scale-out策略与多核技术有些相似，它采用分布式部署的方式将系统的负载分散到多台服务器上，每台服务器处理一部分并发和流量。这样做可以充分利用现有硬件资源，提高系统的整体性能，使系统更能应对大规模并发请求。这种方法在面对硬件性能瓶颈时尤其有用，因为它允许系统水平扩展，而不仅仅依赖于单一硬件性能的提升。

使用缓存提升性能

毫无疑问，Web 2.0 时代是缓存的时代。缓存已经广泛应用于系统设计的各个方面，从操作系统到浏览器，从数据库到消息队列，几乎所有复杂的服务和组件都在使用缓存。主要的目标是提升系统的访问性能，特别是在高并发的场景下，能够支持更多用户同时访问。那么为什么缓存能够显著提升系统性能呢？

我们知道，数据通常存储在持久化存储介质中，而一般的持久化存储介质使用磁盘。普通硬盘由机械手臂、磁头、转轴、盘片等组成，盘片又分为磁道、柱面和扇区。磁盘工作时盘片高速旋转，机械手臂驱动磁头在磁道上寻找并读取所需数据。这个磁头寻找数据所需的时间被称为寻道时间。普通硬盘的寻道时间大约在10毫秒左右。与此相比，CPU执行指令和内存寻址的时间在纳秒级别，从千兆网卡上读取数据的时间在微秒级别。因此，在整个计算机体系结构中，磁盘是最慢的组件之一，甚至比其他组件慢几个数量级。

为了提高性能，通常会使用内存作为存储介质的缓存。内存的访问速度远快于磁盘，因此可以显著减少数据访问时间。当然，缓存的语义已经变得非常丰富，它不仅仅局限于内存缓存，任何降低响应时间的中间存储都可以称为缓存。缓存的思想在许多设计领域都有广泛应用，例如，在操作系统中，CPU具有多级缓存，文件系统使用页面缓存等等。

异步处理

同步方法调用意味着调用方在调用一个方法后会阻塞等待该方法的逻辑执行完成。这种方式下，如果被调用方法的响应时间较长，调用方就会一直阻塞等待，这可能会导致调用方长时间无法响应其他请求。在高并发的情况下，同步调用可能导致整个系统性能下降，甚至发生雪崩效应。

异步方法调用则完全相反。调用方不需要等待被调用方法的逻辑执行完成就可以立即返回并继续执行其他逻辑。被调用方法的执行过程会在后台进行，当执行完毕后，可以通过回调函数、事件通知等方式将结果反馈给调用方。这种方式在大规模高并发系统中被广泛采用。

以 12306 网站为例，当用户订票时，系统可能需要进行复杂的操作，如查询余票、下单、更改余票状态等，这些操作可能需要耗费较长时间。如果采用同步方式，用户将被阻塞等待这些操作完成，导致用户体验差且系统难以承受高并发。但采用异步方式，系统可以将请求丢到消息队列中，然后立即告诉用户正在处理，然后释放资源继续处理其他请求。当订票操作完成后，系统再通知用户订票成功或失败。这种异步处理方式使得系统能够更好地应对高并发，减少了资源占用，提高了系统的性能和可扩展性。

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

我曾经参与了一个创业项目，在初期阶段选择了服务化的架构。然而，由于团队规模有限，技术经验不足，我们在项目开发过程中遇到了一系列问题。这些问题包括难以定位故障、整体系统性能下降，甚至出现系统宕机等。最终，我们不得不将服务整合回到一个简单的单体架构中，放弃了复杂的服务化架构。

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

在系统设计中，最基本的原则是满足业务需求和当前的流量情况，同时选择熟悉的技术体系。
随着流量增加和业务演变，我们需要不断修正系统架构中的问题点，包括单点问题、横向扩展困难以及性能不足的组件。在这个过程中，我们首先考虑选择社区已经广泛验证并且团队熟悉的组件来解决问题。只有当社区中没有合适的解决方案时，才会考虑自行开发新的组件。
当对架构的小修小补无法满足需求时，考虑重构、重写等大的调整方式以解决现有的问题。

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