高并发系统设计--限流

前面学习过的熔断和降级都是通过暂时关闭某些非核心服务或者组件来保护核心系统的可用性。但是并不是所有的场景下都可以使用熔断降级的策略，例如当核心服务产生比较大的影响时，总不能把核心服务进行熔断与降级，些时一般采用限流方案来进行保护。

限流指的是通过限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则只能通过拒绝服务的方式保证整体系统的可用性。限流策略一般部署在服务的入口层，比如 API 网关中。

现实中可以在多个维度上对到达系统的流量做控制，例如：

1. 你可以对系统每分钟处理多少请求做出限制；
2. 可以针对单个接口设置每分钟请求流量的限制；
3. 可以限制单个 IP、用户 ID 或者设备 ID在一段时间内发送请求的数量；
4. 对于服务于多个第三方应用的开放平台来说，每一个第三方应用对于平台方来说都有一个唯一的 appkey 来标识，那么你也可以限制单个 appkey 的访问接口的速率。

限制速率的方式是基于一些限流算法的，那么常见的限流的算法有以下几种：

• 固定窗口与滑动窗口的算法
• 漏桶算法与令牌筒算法

漏桶算法：在流量产生端和接收端之间增加一个漏桶，流量会进入和暂存到漏桶里面，而漏桶的出口处会按照一个固定的速率将流量漏出到接收端。经过了漏桶算法之后，随机产生的流量就会成为比较平滑的流量到达服务端，从而避免了突发的大流量对于服务接口的影响。

令牌桶算法：如果我们需要在一秒内限制访问次数为 N 次，那么就每隔 1/N 的时间，往桶内放入一个令牌；在处理请求之前先要从桶中获得一个令牌，如果桶中已经没有了令牌，那么就需要等待新的令牌或者直接拒绝服务；桶中的令牌总数也要有一个限制，如果超过了限制就不能向桶中再增加新的令牌了。这样可以限制令牌的总数，一定程度上可以避免瞬时流量高峰的问题。

漏桶算法在面对突发流量的时候，采用的解决方式是缓存在漏桶中，会增长响应时间，这与互联网业务低延迟的要求不符；而令牌桶算法可以在令牌中暂存一定量的令牌，能够应对一定的突发流量，一般我会使用令牌桶算法来实现限流方案。

限流策略是微服务治理中的标配策略，只是你很难在实际中确认限流的阈值是多少，设置的小了容易误伤正常的请求，设置的大了则达不到限流的目的。一般通过定期的压力测试得到整体系统以及每个微服务的实际承载能力，然后再依据这个压测出来的值设置合适的阈值。并结合配置中心中来实现动态调整。