星星之火
可以燎原
从六月底到现在大概写了接近50篇文章，终于在第一次修改了公众号名称：二进制跳动,以此来支持声援海外TikTok。打不死的我们，必将使我们更加坚强。
中国加油
所谓的大流量，我们可能会想到TPS(每秒事务数)，QPS（每秒请求量），5000+，10000+，50000+....当然没有一个具体的数据，其实这么说吧，对你的系统造成了压力，影响了系统的性能，这个对于你的系统就叫做大流量。
那么应对大流量的手段有哪些呢？
万变不离其中：让数据尽早进入缓存，离程序近一点，不要频繁的访问DB。
下面就跟我们的RPC基本高级特征有关了。
降级：如果不是核心的作用，就把这个功能降级掉。比如说，我们做推荐系统，千人千面拿到数据后，做个性化排序，如果再大流量下，这个排序的功能就万全可以省去。
限流：这个我们就见得很多了，在现实生活中，在南京的地铁早高峰的时候，一段时间放一批人，这就是限流。说白了，就是在一定的时间段里面，保证系统不被击垮，同时还要尽量的保证系统的吞吐量。
有些比较特别的场景，很出名的就是双十一了，用户的购买，下单都是比较核心的功能，涉及到大量的读写，不能做降级，只能通过限流来保证系统的健壮性。
当然限流有很多种:计数器、滑动窗口、漏桶、令牌。
我今天就聊下令牌桶：
漏桶的出水速度是恒定的，意味着如果瞬时有大流量的话，将有大部分的请求被过滤掉，也就是说溢出。
生成令牌的速度是恒定的，去拿令牌的速度是没有限制的。如果有大量的请求过来的话，该算法可以让你快速拿到令牌，而且拿到令牌的过程不会内耗太大。这个中间虽然会过滤掉不少的正常请求，但是相比于系统的崩溃，还是值得去操作的。
限流神器：Guava RateLimiter(google出品 必属精品！鄙视facebook)
大家可以自行去google下。
这是典型的令牌桶算法，我们只需要告诉RateLimiter系统限制的QPS是多少，那么他就按这个速度往桶里放入令牌，然后请求的时候 调用tryAcquire()方法向RateLimiter获取许可。
那么分布式环境下的限流怎么做呢？
比如Nginx+Lua、Redis+Lua去实现
总结：
让系统的流量先去队列中排队、限流，不要讲流量直接打到系统上，这是关键。