一种高性能限流方案

一个高性能、高可用框架，设计之初至少会从单次响应时间、QPS以及TPS三个维度进行考量，但是要做到4个9的SLA仅仅只有这些还是不够的；在互联网高可用架构设计中，限流是一种经典的高可用保障模式。因为某些原因，大量用户突然访问我们的系统时，或者有黑客恶意用 DoS（Denial of Service，拒绝服务）方式攻击我们的系统时，这种未曾预期的高并发访问对系统产生的负载压力可能会导致系统崩溃。

解决这种问题的一个主要手段就是限流，即拒绝部分访问请求，使访问负载压力降低到一个系统可以承受的程度。

常用限流策略

• 全局限流：针对所有请求进行限流，即保证整个系统处理的请求总数满足限流配置。
• 账号限流：针对账号进行限流，即对单个账号发送的请求进行限流。
• 设备限流：针对设备进行限流，即对单个客户端设备发送的请求进行限流。
• 资源限流：针对某个API（或某个 URL）进行限流，即保证访问该资源的请求总数满足限流配置。

设计思路

构建一个队列，模拟一个特定大小的令牌桶，然后向桶中以特定的速度放入令牌（token），请求到达负载均衡服务器后，必须从桶中取出一个令牌才能继续交由下游处理。如果桶中已经没有令牌了，那么当前请求就被限流，返回 503 响应。如果桶中的令牌放满了，令牌桶也会溢出。

实现概要

• 因不需要校验令牌的有效性，所以这里可以采用redis中的计数器作为存储令牌的数据结构(操作计数器的时间复杂度O(1))

• 后台需要单启一个任务用来生成令牌，这里以计数器为例，伪代码如下：

#假设吞吐量为1000； 不同策略使用key区分
Thread.sleep(1)
current = redis.get(key)
IF current != NULL AND current > 1000 THEN
    pass
ELSE
    redis.incr(key)

• 请求到达后需要先获取令牌才能继续进行，请求每消费一个令牌，计数器会 -1

current = redis.incr(key, -1)
IF current != NULL AND current < 0 THEN
    ERROR (503, "No token currently")

小结

• 令牌桶限流算法综合效果比较好，能在最大程度利用系统资源处理请求的基础上，实现限流的目标
• 如果是业务侧或接口层使用这种限流方案时，还可采用数据降级的方式进行优化处理，针对超过阈值的请求不返回503而是返回提前缓存好的兜底数据，对应用户体验是比较友好的
• 如果需要在逻辑层校验令牌的有效性，那么可以使用List数据类型作为令牌桶存储token值，当请求到达时使用pop命令弹出一个token