滑动窗口算法并非完全避免了边界问题，而是通过降低粒度，减少了发生的概率

老师，怎么觉得令牌桶和固定窗口是同一个算法呢，只不过是令牌桶做的是--，额外需要一个塞令牌的job，固定窗口做的是++。他们都是用过期时间来使时间窗口失效。

老师，比如每秒限流10个，如果使用redis的zset，score作为时间戳（ms），某一时刻1615386799000过来一笔请求 var count = zcount user_1 (1615386799000-1000) 1615386799000; //获取当前时间-1s至当前时间段的请求数 if (count >= 10 ) return "too many request"; zadd user_1 1615386799000 geek; 这样处理是不是也只是把窗口细化到了1ms而已，严格意义上的平滑是不存在的，能做的只是像微积分一样无限逼近，但是在应用中其实已经够用了难道不是么？

老师，如果集中式限流，对于同一个接口请求量如果很大超过50w每秒，对于api网关入口和限流服务由于可以水平扩展是能承受的，但是对于同一个请求都是路由到同一台redis，超过redis承受范围那该如何优化呢。

还有guava的均速限流器

固定窗口：有边界问题； 滑动窗口：将窗口再细粒度划分，实现任一个窗口限流，但还是不能解决比窗口更细粒度的时间内流量高峰，不平滑； 漏桶算法：控制出口，比较平滑； 令牌桶算法：可以预放令牌，有一定的泄洪作用，不平滑。