前言
提到互联网系统设计，你可能听到最多的词儿就是“三高”，也就是“高并发”，“高性能”，“高可用”。
作为一名合格的架构师，需要在充分了解业务需求的情况下，根据实际经验和理论知识，设计和实现能够支撑三高要求的系统。
本文主要针对高并发的场景, 讲解应对之法。
解决方案
所谓高并发，即代表着大流量，高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案，从而抵抗巨大流量的冲击，带给用户更好的使用体验。这些方案好似能操纵流量，让流量更加平稳的被系统中的服务和组件处理。
而我们在应对高并发大流量时也会采用类似“抵御洪水”的方案，归纳起来共有三种方法。
- Scale-out（横向扩展） 分而治之是一种常见的高并发系统设计方法，采用分布式部署的方式把流量分流开，让每个服务器都承担一部分并发和流量。
- 缓存 使用缓存来提高系统的性能，就好比用“拓宽河道”的方式抵抗高并发大流量的冲击。
- 异步 在某些场景下，未处理完成之前，系统可以让请求先返回，在数据准备好之后再通知请求方，这样可以在单位时间内处理更多的请求。
简单介绍了这三种方法之后，本文继续详细说明，这样当你在设计高并发系统时就可以有考虑的方向了。
Scale-out
Scale-up vs Scale-out
摩尔定律是英特尔创始人之一戈登·摩尔的经验之谈，其核心内容为：集成电路上可以容纳的晶体管数目在大约每经过 18 个月到 24 个月便会增加一倍。换言之，处理器的性能大约每两年翻一倍，同时价格下降为之前的一半。
摩尔定律是内行人摩尔的经验之谈，但并非自然科学定律，它一定程度揭示了信息技术进步的速度。
摩尔定律虽然描述的是芯片的发展速度，但我们可以延伸为整体的硬件性能，从 20 世纪后半叶开始，计算机硬件的性能是指数级演进的。
但是有专家预测，摩尔定律可能在未来几年之内不再生效，原因是目前的芯片技术已经做到了 10nm 级别，在工艺上已经接近极限，再往上做，即使有新的技术突破，在成本上也难以被市场接受。
后来，双核和多核技术的产生拯救了摩尔定律，这些技术的思路是将多个 CPU 核心压在一个芯片上，从而大大提升 CPU 的并行处理能力。
高并发系统设计上也沿用了同样的思路，将类似追逐摩尔定律不断提升 CPU 性能的方案叫做 Scale-up（纵向扩展），把类似 CPU 多核心的方案叫做 Scale-out，这两种思路在实现方式上是完全不同的。
Scale-up，通过购买性能更好的硬件来提升系统的并发处理能力，比方说目前系统 4 核 4G 每秒可以处理 200 次请求，那么如果要处理 400 次请求呢？很简单，我们把机器的硬件提升到 8 核 8G（硬件资源的提升可能不是线性的，这里仅为参考）。但是这种方式不仅仅只增加了处理能力，还需要提升宽带、计算能力、容量。所以，整个系统很快就会达到性能瓶颈，需要继续扩展。
Scale-out(横向扩展)架构的升级通常是以节点为单位，每个节点往往将包含容量、处理能力和 I / O 带宽。一个节点被添加到存储系统，系统中的三种资源将同时升级。它通过将多个低性能的机器组成一个分布式集群来共同抵御高并发流量的冲击。沿用刚刚的例子，我们可以使用两台 4 核 4G 的机器来处理那 400 次请求。
那么什么时候选择 Scale-up，什么时候选择 Scale-out 呢？一般来讲，在我们系统设计初期会考虑使用 Scale-up 的方式，因为这种方案足够简单，所谓能用堆砌硬件解决的问题就用硬件来解决，但是当系统并发超过了单机的极限时，我们就要使用 Scale-out 的方式。
Scale-out 虽然能够突破单机的限制，但也会引入一些复杂问题。比如，如果某个节点出现故障如何保证整体可用性？当多个节点有状态需要同步时，如何保证状态信息在不同节点的一致性？如何做到使用方无感知的增加和删除节点？每个问题都存在涉及到很多知识点，本文暂不一一陈述。
缓存
缓存是提升系统高并发的一大利器。缓存的使用遍布在系统设计的每个角落，从操作系统到浏览器，从数据库到消息队列，任何略微复杂的服务和组件中，都会引入缓存。
操作系统缓存机制如下图所示：
我们使用缓存的主要作用是提升系统的访问性能，那么在高并发的场景下，就可以支撑更多用户的同时访问。
那么为什么缓存可以大幅度提升系统的性能呢？我们知道数据是放在持久化存储中的，一般的持久化存储都是使用磁盘作为存储介质的，而普通磁盘数据由机械手臂、磁头、转轴、盘片组成，盘片又分为磁道、柱面和扇区。
普通磁盘的寻道时间是 10ms 左右，而相比于磁盘寻道花费的时间，CPU 执行指令和内存寻址的时间都在是 ns（纳秒）级别，从千兆网卡上读取数据的时间是在 μs（微秒）级别。
所以在整个计算机体系中，磁盘是最慢的一环，甚至比其它的组件要慢几个数量级。因此，我们通常使用以内存作为存储介质的缓存，以此提升性能。当然，任何降低响应时间的中间存储都称为缓存。缓存的思想遍布很多设计领域，比如在操作系统中 CPU 有多级缓存，文件有 Page Cache 缓存，浏览器会缓存图片等静态资源，Mybatis 也有一级缓存和二级缓存。
后续小面会详细对缓存架构设计做进一步介绍，敬请期待！
异步处理
异步也是一种常见的高并发设计方法，我们在很多文章和演讲中都能听到这个名词，与之共同出现的还有它的反义词: 同步。
比如，分布式服务框架 Dubbo 中有同步方法调用和异步方法调用，IO 模型中有同步 IO 和异步 IO。
那么什么是同步，什么是异步呢？以方法调用为例，同步调用代表调用方要阻塞等待被调用方法中的逻辑执行完成。这种方式下，当被调用方法响应时间较长时，会造成调用方长久的阻塞，在高并发下会造成整体系统性能下降甚至发生雪崩。
异步调用恰恰相反，调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑，在被调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。
异步调用在大规模高并发系统中被大量使用，比如我们熟知的 12306 网站。
当我们订票时，页面会显示系统正在排队，这个提示就代表着系统在异步处理我们的订票请求。
在 12306 系统中查询余票、下单和更改余票状态都是比较耗时的操作，可能涉及多个内部系统的互相调用，如果是同步调用就会像 12306 刚刚上线时那样，高峰期永远不可能下单成功。
而采用异步的方式，后端处理时会把请求丢到消息队列中，同时快速响应用户，告诉用户我们正在排队处理，然后释放出资源来处理更多的请求。订票请求处理完之后，再通知用户订票成功或者失败。
处理逻辑后移到异步处理程序中，Web 服务的压力小了，资源占用的少了，自然就能接收更多的用户订票请求，系统承受高并发的能力也就提升了。
总结
以上介绍了应对高并发的这三种方法，但是这并不意味着在高并发系统设计中，开发一个系统时要把这些方法都用上。
实际的系统设计要考虑实际的业务量级和业务痛点，不能盲目按照百万级、千万级并发量设计系统，需要考虑人力、时间、团队水平、项目预算等因素。
所以本文建议一般系统的演进过程应该遵循下面的思路：
最简单的系统设计满足业务需求和流量现状，选择最熟悉的技术体系。
随着流量的增加和业务的变化，修正架构中存在问题的点，如单点问题，横向扩展问题，性能无法满足需求的组件。在这个过程中，选择社区成熟的、团队熟悉的组件帮助我们解决问题，在社区没有合适解决方案的前提下才会自己造轮子。
当对架构的小修小补无法满足需求时，考虑重构、重写等大的调整方式以解决现有的问题。
归根结底一句话：高并发系统的演进应该是循序渐进，以解决系统中存在的问题为目的和驱动力的。
