分布式系统关注点——限流该怎么做？

在上一篇中我们聊到了「熔断」（分布式系统关注点——99% 的人都能看懂的「熔断」以及最佳实践），有熔断机制的系统，它对可用性的作用至少保证了不会全盘崩溃。

但是你可以想象一个稍微极端一点的场景，如果系统流量不是很稳定，导致频繁触发熔断的话，是不是意味着系统一直熔断的三种状态中不断切换。

导致的结果是每次从开启熔断到关闭熔断的期间，必然会导致大量的用户无法正常使用。系统层面的可用性大致是这样的。

另外，从资源利用率上也会很容易发现，波谷的这段时期资源是未充分利用的。

由此可见，光有熔断是远远不够的。

在高压下，只要系统没宕机，如果能将接收的流量持续保持在高位，但又不超过系统所能承载的上限，会是更有效率的运作模式，因为会将这里的波谷填满。

在如今的互联网已经作为社会基础设施的大环境下，上面的这个场景其实离我们并不是那么远，同时也会显得没那么极端。例如，层出不穷的营销玩法，一个接着一个的社会热点，以及互联网冰山之下的黑产、刷子的蓬勃发展，更加使得这个场景变的那么的需要去考虑、去顾忌。因为随时都有可能会涌入超出你预期的流量，然后压垮你的系统。

那么限流的作用就很显而易见了：只要系统没宕机，系统只是因为资源不够，而无法应对大量的请求，为了保证有限的系统资源能够提供最大化的服务能力，因而对系统按照预设的规则进行流量（输出或输入）限制的一种方法，确保被接收的流量不会超过系统所能承载的上限。

一、怎么做「限流」

从前面聊到的内容中我们也知道，限流最好能“限”在一个系统处理能力的上限附近，所以：

1. 通过「压力测试」等方式获得系统的能力上限在哪个水平是第一步。

2. 其次，就是制定干预流量的策略。比如标准该怎么定、是否只注重结果还是也要注重过程的平滑性等。

3. 最后，就是处理“被干预掉”的流量。能不能直接丢弃？不能的话该如何处理？

获得系统能力的上限

第一步不是我们这次内容的重点，说起来就是对系统做一轮压测。可以在一个独立的环境进行，也可以直接在生产环境的多个节点中选择一个节点作为样本来压测，当然需要做好与其他节点的隔离。

一般我们做压测为了获得 2 个结果，「速率」和「并发数」。前者表示在一个时间单位内能够处理的请求数量，比如 xxx 次请求 / 秒。后者表示系统在同一时刻能处理的最大请求数量，比如 xxx 次的并发。从指标上需要获得「最大值」、「平均值」或者「中位数」。后续限流策略需要设定的具体标准数值就是从这些指标中来的。

题外话：从精益求精的角度来说，其他的诸如 cpu、网络带宽以及内存的耗用也可以作为参照因素。

制定干预流量的策略

常用的策略就 4 种，我给它起了一个简单的定义——「两窗两桶」。两窗就是：固定窗口、滑动窗口，两桶就是：漏桶、令牌桶。

固定窗口有一点需要注意的是，假如请求的进入非常集中，那么所设定的「限流阈值」等同于你需要承受的最大并发数。所以，如果需要顾忌到并发问题，那么这里的「固定周期」设定的要尽可能的短。因为，这样的话「限流阈值」的数值就可以相应的减小。甚至，限流阈值就可以直接用并发数来指定。比如，假设固定周期是 3 秒，那么这里的阈值就可以设定为「平均并发数 *3」。

不过不管怎么设定，固定窗口永远存在的缺点是：由于流量的进入往往都不是一个恒定的值，所以一旦流量进入速度有所波动，要么计数器会被提前计满，导致这个周期内剩下时间段的请求被“限制”。要么就是计数器计不满，也就是「限流阈值」设定的过大，导致资源无法充分利用。

「滑动窗口」可以改善这个问题。

滑动窗口

滑动窗口其实就是对固定窗口做了进一步的细分，将原先的粒度切的更细，比如 1 分钟的固定窗口切分为 60 个 1 秒的滑动窗口。然后统计的时间范围随着时间的推移同步后移。

限流就好比保险丝，根据你制定的标准，达到了就拉闸。

不过，触发限流后的措施除了直接丢弃请求之外，还有一个方式是「降级」，那么降级有哪些方式呢？我们下一篇再聊吧。

Question：

你在工作中有遇到过什么场景需要做「限流」吗？欢迎分享交流一下。

关于作者：张帆（Zachary），7 年电商行业经验，5 年开发团队管理经验，4 年互联网架构经验。专注大型系统架构、分布式系统。坚持用心打磨每一篇原创。本文首发于公众号：跨界架构师（ID：Zachary_ZF）。