35 | 流量控制：高并发系统中我们如何操纵流量？

听老师的课，每次都有收获，给老师点个赞。 限流方式有如下： 1、固定窗口 2、滑动窗口 3、漏斗，一般用队列来实现，但是会造成请求有延迟并且也对处理突发流量不友好。 4、令牌桶，通过往桶内定时放入一个令牌，请求过来时先要申请到令牌才能继续，否则请求失败，这个对于处理突发流量时比较友好，即平时可以攒，到突发流量时可以直接用起来，guava的ratelimiter就是令牌桶算法实现的，分布式令牌桶可以用redis来实现，可以一次申请多个而不是一个这样可以降低每次请求的开销。

令牌桶以及漏桶算法的分布式实现有可以参考的么？

自我感觉，流浪控制跟消息队列的原理类似。 都是把突发请求，采用类似于分片的方式，分批处理。降低响应速度，但是却都能响应，不会导致宕机。 令牌桶的思路，也偏向于地铁限流的策略：每隔一定的时间，放进来一定数量的乘客，虽然每个乘客的平均等待时间更长了，但是却防治了地铁被挤爆，发生危险。 另外老师，我想说另一个问题是，地铁的限流，我觉得不单单是防止地铁站被挤爆。我觉得主要是考虑后面站点的乘客问题。 假设：地铁有站点 1 2 3 一辆地铁能容纳1000人，地铁五分钟一趟，站点1每5分钟有客流量1000人。考虑地铁的承载能力，就算第一站全部放进来也可以，但是由于地铁乘客大概率都会乘坐2站以上，就会导致第2，3站点有大量乘客长时间等待。所以，地铁站限流也是为了给后面的站点留出一定的运载额。

批量获取令牌后怎么处理呢？放到服务的本地缓存中吗？还是另起一个新的redis 缓存？如果新开一个redis 缓存，和直接取区别不大吧？如果本地的内存缓存，也不见得比直接从redis 取快多少吧，可能会快一丢丢，毕竟所有的请求都直接从redis 取，压力会比较大，相当于把redis中的数据打散到各个服务再处理

看到评论说业界，没有成熟的方案，这里就要捶你了。开发:rateLimit,semaphore，框架：阿里的sentiel以及它的各种限流产品

这周刚开始学习老师的课程，算法训练营刚基本结束，就继续开始知识的强化，下周老师基本上能赶上进度，学习中可能会在后续的提出一些前面课程的困惑希望老师不吝赐教。 限流的用户体验太差了：令牌桶算法和漏桶算法确实不错，有生产环境用限流不过体验非常差，每年次数不多且.net系的似乎没用好的策略，故而都是暴力的增加带宽去解决。 老师在课程小结前面的"我们可以在每次取令牌的时候，不再只获取一个令牌，而是获取一批令牌，这样可以尽量减少请求 Redis 的次数。"这个其实稍有问题，个人觉得改成"我们可以在每次取令牌的时候，不再只获取一个令牌，而是通过MQ获取一批令牌，这样可以尽量减少请求 Redis 的次数。"更为符合生成环境的操作。 数据系统/中间件存储已经不再是当初的CS或BS开发架构：高并发分布式架构其实就是要充分利用这些组件，带来的问题就是运维复杂。不过我记得陈皓老师说过"运维优先，做平台的思路就是一定要能维护好"，这其实是许多中小企业不重视的方面且觉得无所谓的方面，从而导致了大量设计思路的错误，造成了大量的不必要的高并发。有时加个组件就能完成-前提是你对它足够了解。 今年在中小电商平台经历过其多套系统，典型的问题还是系统的合理性已经维护的问题带来了大量的高并发，数据系统中的某些组件性能优化做到后相比过去有了极其显著的提升，让慢查询比例缩短至过去10-15%，可是依然在某些峰之上还是有问题。流量控制其实涉及到的不是数据库而是数据系统和整体系统的性能维护，这是我觉得很多技术负责人没有看到的问题。 期待老师后续的分享：后续的课程中会有一些前面的问题，还望老师不吝赐教-谢谢。

限流一般在rpc调用端做吗？还是被调用端？

令牌桶算法中令牌是否有过期的概率？例如每秒钟限制是100,则每10ms放入一个令牌，如果令牌桶中令牌的最大值是1000。在某一端时间内一直没有流量,令牌桶中令牌到达了最大值，之后的1s内来了1000次请求，那都能获取到令牌。这样岂不是不能起到限流的作用?

这两个方法也是阿里在用的方法 阿里有一本书叫决战双11中提到的限流 就是这两个方法

前不久做了一个一句话需求：同一个用户每5秒只能提交一次订单，每天只能提交最多200次订单。采用的方式就是固定窗口请求计数的粗爆算法，简单快捷。最终每天的请求量汇总用来做数据分析。我在考虑是不是可以用令牌桶算法来实现地更优雅一些呢？