架构师的十八般武艺：高并发架构

IT 应用，特别是互联网应用，面临的是大量用户的并发访问。并且系统的可用性很大程度决定了商业价值。同时由于部分特殊场景如大促、秒杀的存在，还存在超大流量的冲击。如何让应用系统能应对高并发的流量，是架构师必须面对的问题。

针对高并发的架构设计，无非就是三句话十二个字：知己知彼、分层分流、合理保护。

知己知彼，很简单就是需要知道自身系统的容量上限，知道可能的访问流量。

对于知己，无非就是通过压测解决。压测的方式有两种：

1. 线下压测得出单集群的容量，然后推算线上环境的容量。这种方式需要建立在推算逻辑是正确的前提下。但是，一个应用系统的容量，往往是由最短的木板决定的。最短的木板大概率出现在后端存储、网络、缓存等。而且，并不是太容易估算。

2. 线上压测。这个方式最早是应对双 11 提出来的。思路非常新颖。如何做线上压测，这是一个大学问。首先，线上压测会更容易得到应用系统的容量上限。其次，线上压测需要不影响或者最少影响真实的交易，这里就需要做到隔离和保护。最后，线上压测如何和真实流量分离，并做好事后的数据清洗，这就要求建立影子链路或者可以对压测流量数据打标。

对于知彼，首先需要根据过往的经验，预估可能的业务量。然后根据理论分解或者线上实际压测的方式，推演出该业务量对于各应用系统的压力。因为不同的业务组合、不同的访问模式，对于系统的负荷分布是不一样的。比如信用卡支付，对于金融网关的压力会比较大；花呗/余额等，压力会被转移到账务系统上；大促之后，可能物流和资金清算系统的压力会在某一时刻增大等。

分层分流就是指对于大流量几种典型的应对模式。互联网架构下，单机的容量往往是比较低的。所以，针对大的访问量，首选需要做切分：

1. 垂直切分：将应用系统划分成不同的领域，如用户域、订单域、支付域、资金域等。对于不同的域，用独立的集群去承载。同时根据不同域的特点，采用最适合的存储模式。比如用订单域，流水型数据为主，交易之间几乎没有关联，非常适合用 NoSQL。对于资金域的账务系统，需要有高一致性保证，同时借贷的复式记账模式，更适合关系数据库。

2. 水平切分：这个就是通常说的分库分表。按照用户维度将数据分散到不同的集群处理，减少对单机群的压力。同时，用一致性 hash 的算法，实现按需的静态扩容，例如 8 库->16 库->32 库等。

其次，对于大量的只读请求，需要做到缓。通过在前面增加缓存的方式，将热点访问通过缓存消化掉，减少对后端存储的压力。

最后，对于一些特殊的流量，需要能做到蓄。蓄一般通过异步化处理：

1. 对于突发的流量，通过消错队列实现错峰填谷，应对突发的尖刺流量。

2. 对于一些热点的访问，通过先受理后处理的异步化方式，将热点请求延迟处理和合并处理。

蓄无非就是用时间换空间。