如果这是第二次看到我的文章，欢迎右侧扫码订阅我哟~  👉

本文长度为5269字，预计读完需1.2MB流量，建议阅读14分钟。

可能你在网上看过不少「限流」相关的文章，但是z哥的这篇可能是最全面，最深入浅出的一篇了（容我飘几秒～）。

开个玩笑，希望你能收获一些增量价值就好～。

之前有了解到z哥的一部分读者们没有充分搞清楚「限流」和「熔断」的关系。我们先来思考一个问题，生活中也有限流，为什么国庆春节长假热门景点要限流？而不是一早先开几小时，如果人多了就关几小时，人少了就再开呢？其实这就是限流和熔断表象上的一个区别。

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

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

▲点击图片可查看大图

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

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

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

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

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

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

一、怎么做「限流」

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

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

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

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

获得系统能力的上限

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

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

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

制定干预流量的策略

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

固定窗口

固定窗口就是定义一个“固定”的统计周期，比如1分钟或者30秒、10秒这样。然后在每个周期统计当前周期中被接收到的请求数量，经过计数器累加后如果达到设定的阈值就触发「流量干预」。直到进入下一个周期后，计数器清零，流量接收恢复正常状态。

这个策略最简单，写起代码来也没几行。