若某2fsk系统的码元传输速率_谈谈高并发系统限流策略

1. 从服务器的吞吐能力来考量

吞吐率，一般用于表示服务器的并发处理能力。即：单位时间内服务器处理的请求数来描述服务器的并发处理能力，单位是：reqs/s

所谓服务器所支持的最大并发数，具体到了服务的业务上游，大部分不会是1对1的关系，一个真实的上游可能带来多个并发数压力。

从web服务器的角度来看，一般会限制同时请求的最大连接数，比如：

Nginx的参数
limit_conn one 100 表示最大并发连接数100
limit_conn perserver 1000 表示该服务提供的总连接数不得超过1000,超过请求的会被拒绝

2. 业务场景

某个部门按照业务方需求，开发实现了一个API对外提供服务，所有功能测试正常，按期完成交付。

突然有一天，部门研发A发现自己开发的接口请求量突然激增到之前的10倍，没过多久，这个接口基本处于不可用的状态，引发系统雪崩。

那么这种情况该如何应对呢？

举个生活中常见的栗子：小时候家里经常出现停电的情况，一般是老式电闸里的保险丝熔断导致，一旦一个楼层某家用了超大功率电器（电暖气、空调等），保险丝就会熔断，以保证其他电器不别强电流烧坏。

这个栗子告诉我们，服务器API也需要加上"保险丝"，当流量过大的时候，要采取相应的措施，以防过大的请求压力造成整个系统瘫痪。

那么服务器一般采用什么措施呢？ 限流

3. 常见的限流措施

限流是对某一段时间窗口内的请求数进行限制，保持系统的可用性和稳定性，防止因流量暴增而导致的系统运行缓慢或者宕机，一旦达到限制速率则可以拒绝服务、排队等待或是降级处理。

比如我们在调用常见的openAPI（微信公众平台接口、百度地图接口等）时候会发现会有每天调用多少次或者每分钟最多请求次数的限制。

那么这些限流的常用实现方法是怎样的呢？常用的限流算法有两种：漏桶算法和令牌桶算法。

（1）漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。

（2）对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。

令牌桶算法能够保持稳定的流量上限，同时也允许偶尔的流量爆发。

如图所示：令牌桶算法的原理是系统会以一个恒定的速度r往一个容量有限的桶里放入令牌，由于桶的容量是有限的，所以不可能无限制的往里面添加令牌，如果令牌超过桶的容量最大值的时候，桶此时已经装满令牌，那么再进入的令牌就被抛弃了。每次request请求，就会有n个数量的令牌从桶里面被移除，如果桶里面的令牌数少于n，那么该请求就会被拒绝，说明令牌不够用了，需要等桶里令牌满足服务请求数的要求才可以继续提供服务。

4. Redis实现令牌桶算法的栗子

比如你设计的接口API，希望将速率限制在每分钟4次请求，同时允许偶尔的流量激增，但是最大不得超过每分钟8次。

业务流程图如下：

设计如下：

（1）用户第一次请求，Init Bucket，这个桶最大容量为8（即能够装8个令牌），将请求的时间戳和令牌的数量存到Redis里，使用用户的UID作为Key；

（2）后续的请求里，按照预定的固定速率15s(4/60s)向桶里填充新的令牌token；

（3）从桶里删除一个令牌，并把时间戳更新为当前时间；

（4）如果可用的令牌数为0，拒绝请求。

这篇文章就整理到这里，Done！

5. 参考文章

https://www.sohu.com/a/316208735_468635https://www.cnblogs.com/xuwc/p/9123078.htmlhttps://www.cnblogs.com/cjsblog/p/9379516.html