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

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