高并发是一种架构思维模式

上文说到，性能是高并发的目标之一。 追求性能没有错，但并非永无止境 。想要提升性能，势必投入成本，不过它们并不是一直成正比，而是随着成本不断增加，性能提升幅度逐渐衰减，甚至可能不再提升。所以，有时间我们要懂得适可而止。

思考一下，追求性能是为了解决什么问题，至少有一点，是为 了让应用系统能够应对突发请求 。换言之，如果能解决这个问题，是不是也算实现了高并发的目标。

而有时候，我们在解决问题时，不要总是习惯做加法，还可以尝试做减法，架构设计同样如此。那么，如何通过做减法的方式，来解决应对突发请求的问题呢，让我们来讲讲限制。

限制，从狭义上可以理解为是一种约束或控制能力。在软件领域中，它可以针对功能性或非功能性，而在高并发的场景中，它更偏向于非功能性。

限制应用系统的处理能力，并不代表要降低应用系统的处理能力，而是 通过某些控制手段，让突发请求能够被平滑地处理 ，同时起到应用系统的保护能力，避免瘫痪，还能将应用系统的资源进行合理分配，避免浪费。

那么，到底有哪些控制手段，既能实现以上这些能力，又能减少对客户体验上的影响，下面就来介绍几种常用的控制手段。

第一招：限流

限流，是在一个时间窗口内，对请求进行速率控制。若请求达到提前设定的阈值时，则对请求进行排队或拒绝。常用的限流算法有两种：漏桶算法和令牌桶算法。

漏桶算法，所有请求先进入漏桶，然后按照一个恒定的速率对漏桶里的请求进行处理，是一种控制处理速率的限流方式，用于平滑突发请求速率。

它的优点是， 能够确保资源不会瞬间耗尽 ，避免请求处理发生阻塞现象，另外，还能够保护被应用系统所调用的外部服务，也免受突发请求的冲击。

它的缺点是， 对于突发请求仍然会以一个恒定的速率来进行处理 ，其灵活性会较弱一点，容易发生突发请求超过漏桶的容量，导致后续请求直接被丢弃。

令牌桶算法，应用系统会以一个恒定的速率往桶里放入令牌，请求处理前，会从桶里获取令牌，当桶里没有令牌可取时，则拒绝服务，是一种平均流入速率的限流方式。

它的优点是， 在限制平均流入速率的同时，还能在面对突发请求的情况下，确保资源被充分利用 ，不会被闲置或浪费。

它的缺点是， 舍弃了处理速率的强控制能力 ，那么如果某些功能依赖外部服务，可能将会让外部服务无法承受压力，导致无法正常返回，而且还浪费了这次获取的令牌。

综上，两种算法并没有绝对的好坏，而是需要根据实际的情况，选择合适的方式，从而在发挥限流作用的同时不会引发其他问题。但在一些秒杀活动中，软件党的高频请求，会很容易触发限流，导致大量正常请求被误杀的问题。

虽然在请求被限流后，会返回友好话术，减轻对客户体验的影响，但也有可能他们的请求，会一直无法得到有效处理，这时候耐心再好的客户也会离开及抱怨。

所以，我们除了使用限流这招外，还得搭配其他的招数组合一起使用，从而让应用系统能够对资源进行合理分配，避免资源浪费，减少正常请求被误杀的情况。

第二招：降频

降频，是在一个时间窗口内，对同一特征的请求进行速率控制。若请求达到提前设定的阈值时，则会对请求进行拒绝。

虽然和限流有点类似，但存在着细微的差别。对限流而言，它并不关心请求方，而只对服务端的速率进行控制，而对降频而言，它会 基于某种特征，对请求方的请求速率进行控制 。

而降频的目的，是为了减少应用系统资源被不正常的请求所消耗，而导致正常的请求因限流被拒绝的情况发生。它的实现方式也有多种，而且在前端和后端都可以使用。

识别不正常的请求是降频的第一步，也是最关键的一步。一般会制定某种特征+某段时间+请求数量这种三段式的识别规则。

特征可以是账号、会话、IP地址、设备号等，时间一般会是1秒，也可以设置更长。账号+1秒+5笔，意思就是同一个账号在1秒内可以发生5笔请求，但是这里请求数量与限流的设定参考依据不同。

限流大小主要依据性能来决定，而降频中的请求数量，一般会以正常人的交互速率作为参考。所以，并不能因为性能好，就设定账号+1秒+100笔这种识别规则，这不但不科学还会浪费资源。

接下来，有了识别规则还得搭配对应的处置手段，常见的有两种模式：挑战和拒绝。

挑战弹出验证码，输入并验证通过后，可以继续请求仅适用于前端拒绝弹出“请求频繁”提示，且这笔请求将直接被拒绝适用于前端及后端

限流会发生误杀，难道降频就不会吗，其实也会发生，特别是用户的网络环境是一个出口IP地址时。所以，如果是基于IP地址特征的识别规则，请求数量建议适当放大。

在降频策略方面，建议配置多层+渐进式的方式 ，识别规则较为严格的采用挑战模式，识别规则较为宽松的采用拒绝模式，减少因降频而引发的误杀情况，参考如下：

不过，你可以将此视为一种攻防战，通过增强防守的方式，来提高攻击者成本，而攻击者一定会权衡成本和收益，当成本大于收益时，可能就不会有攻击，毕竟没有人会这么无聊透顶。

虽然有了限流和降频这两招，但仍可能无法应对高并发的场景，况且在初期，限流和降频的策略，也无法设计得非常完美。所以，有些时候还得使出最后一招。

第三招：降级

降级，是当应用系统处理超载时，对其服务进行裁剪的一种机制。常见的是应用系统处理阻塞时，会关闭非核心服务，并将资源给到核心服务，从而确保核心服务正常。

经常有人将它与熔断混为一谈，但并非一回事。 降级主要是针对应用系统本身 ，若处理能力不足则可触发，而熔断主要是针对应用系统所调用的外部服务，若外部服务不稳定时则可触发。

当然，两者也有一定的关系，因为当发生熔断时，也可以触发降级机制，比如当同步调用外部服务出现性能问题时，可以降级为异步调用，避免造成线程阻塞而瘫痪。

不过在降级前，必须得先梳理应用系统中的核心服务 ，可以采用经典的二八原则，将服务划分为20%核心服务+80%非核心服务。而这种分法的意图，是希望让你找到真正重要的核心服务，不然，你会觉得都很重要。

在梳理过程中，建议 通过多个维度来进行综合评判，如下是我经常采用的一种梳理方法，你可以将此作为一种参考，并结合自己的服务分类标准进行调整。

首先，可以设计一张类似如下的矩阵图，请尽量地简约它，将应用系统中的各类服务，按照矩阵所设定的不同属性进行分门别类。

用户登录不了无法订单支付，订单查询不了无法订单退货。所以，我们还需引入服务关键路径的概念，可以理解为在使用某个服务前，还必须要使用的其他服务。

分别对挑选出来的核心服务，进行服务关键路径的梳理。

• 路径1：用户登录——>商品查询——>订单下单

• 路径2：用户登录——>商品查询——>订单下单——>订单支付

• 路径3：用户登录——>订单查询——>订单退货

待服务关键路径梳理完成后，再对路径上的所有服务进行合并及去重，将会得到一组新的核心服务：用户登录/商品查询/订单下单/订单支付/订单查询/订单退货。

来计算下核心服务的占比，所有服务14个/核心服务6个，占42.86%，远远超过了20%。所以，建议继续从这些核心服务中，识别更核心的部分，但仍然以服务关键路径为整体。

相比订单下单/订单支付/订单退货这三条服务关键路径，我想订单支付可能会更有价值。最后，我们可以仅将订单支付这条服务关键路径上的服务作为核心服务。

重新再来计算下核心服务的占比，所有服务14个/核心服务4个，占28.57%，虽然还是超过了20%，但这并不是重点，重点是我们已经找到了最核心的服务。

其余的核心服务，可以降级为准核心服务，重组后得到如下这份服务重要程度清单。

以上只是一种相对较粗的降级策略，如果你想要制定更精细化的降级策略，还需要对每个服务进行优先级的设定，高低依据可以结合自身需要来制定，例如：历史服 务使用情况。

当有了限流、降频、降级这三招，基本就能够在资源有限的情况下，让突发请求能够被平滑地处理，将应用系统的资源能够被合理地分配，以及当应用系统处理堵塞时，确保核心服务正常。

现在，我们已经基本了解了如何衡量性能的指标，以及大致掌握了如何保护应用系统的招数。但这些就是高并发全部了吗，我想说这仅仅只是入门级别。

上述内容，主要是为了让你能够清晰地看到应用系统的性能水位在哪里，以及在资源有限下，当面对突发请求时可以采取哪些招数，能让应用系统安全地存活下来。

存活，即代表着可用性，它也是高并发的一个特性，而且是我认为相对比较重要的特性。设想一下，如果你的应用系统连可用性都无法保证，那再高的性能又有何意义。

对于大部分应用系统而言，大家都会比较关注应用系统的可用性，99.9%不够那就99.99%，甚至还有想做到99.999%的，毕竟可用性的不足会直接影响到业务运作。

但对于一个想成为高并发的应用系统而言， 仅单方面关注高可用，肯定无法称得上这个头衔 ，它仍然还需要在其他特性上具备极佳的表现。

让我们拉回到最初的目标，性能是高并发的目标之一，不过，这里我们不再谈论性能指标，而是来研究如何来提升性能。因为，高性能是高并发的另外一个重要特性。

想要提升性能，势必投入成本。随着成本不断增加，性能提升幅度逐渐衰减。这两句话，是不是觉得有点耳熟，但不管你是否还记得，先让我在这里打个问号再说。

在架构设计的过程中，你是否经常会听到“取舍”的这个词，它是 通过牺牲一种能力来换取另外一种能力的方式 ，这些能力可以是性能、可用性、数据一致性或是其他能力。

等等，你是不是突然有意识到，提升性能并不只有投入成本这种方式，至少是在硬件资源方面，我们还可以通过牺牲一种能力去换取。那到底选择牺牲哪种能力呢，牺牲可用性，一般不会第一时间考虑，那是不是可以考虑牺牲数据一致性。

但在考虑前得先声明一下， 所谓牺牲数据一致性，并不是完全不要，而是将数据强一致性降级为最终一致性 。而对于数据最终一致性的理解，就是在数据更新后，要过一段时间后才能看到，而时间的长短就代表着牺牲了多少。

但并不是说，所有情况都必须牺牲数据一致性来提升性能，有些时候也可以考虑牺牲其他能力。但在取舍前，得先弄清楚当前要什么，但更需要弄清楚当前可以失去什么，不合理的取舍，不但无法换取收益，反而还会引来更多的问题。

情况1：数据缓存

缓存，是高并发架构设计中一种不可或缺的能力，一般是指那些经常被访问的热点数据，可以将它放入缓存中，从而提升数据被读取的效率。

但是否所有的数据都适合放入缓存中，如果是静态数据，那么你可以很安心地放入。原因很简单，静态数据不会更新，那么缓存和数据源始终保持一致，而且就算缓存中的数据丢失了，至少还有一份在数据源。

通过将静态数据缓存，可以很轻易地提升静态数据的访问性能，甚至可能是几十倍的效果。但应用系统中还有大量的动态数据， 仅提升静态数据可能对总体的提升并不一定显著 。

你是不是想说，那就把动态数据也放入缓存中不就行了。在下这个决定前，建议你先想一下，动态数据是会更新的，这就意味着动态数据在放入缓存后，当数据源中的数据被更新后，再次访问返回的都是更新前的数据，这种效果你是否可以接受。

我想应该没有人会接受吧，而你是不是又想说，设置下缓存会过期不就能解决了。没错，但得等过期后才能解决，那还没过期前呢，这种方式只能缓解，但并不能根治，而且还会引入一个新的问题，请问过期设置多久才合适。

设置缓存5秒钟过期，可能永远无法命中缓存，而且不但没有提升性能，还增加了代码复杂度，有点画蛇添足的感觉。设置缓存5分钟过期，命中缓存的几率可能会提高，但缓存后在5分钟内的如果数据更新，要从缓存开始往后推5分钟才能看到。

即：第1分钟缓存，第1-6分钟内的任何数据更新，要第6分钟后才能看到。

所以，如果你无法容忍这种情况，请你不要滥用缓存， 虽然性能提高了，但问题可能也出现了 。反之，如果你可以容忍这种情况，那就可以这么操作，而至于过期设置多久，可以结合业务场景及使用频率综合来评估，毕竟不同的业务容忍度是不同的。