正文
令牌桶和漏桶对比
-
令牌桶是按照固定速率往桶中添加令牌，请求是否被处理需要看桶中令牌是否足够，当令牌数减为零时，则拒绝新的请求。
-
漏桶则是按照常量固定速率流出请求，请求流入速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝。
-
令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿多个令牌），并允许一定程序的突发流量。
-
漏桶限制的是常量流出速率（即流出速率是一个固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），从而平滑突发流入速率。
-
令牌桶允许一定程序的突发，而漏桶主要目的是平滑流入速率。
-
两个算法实现可以一样，但是方向是相反的，对于相同的参数得到的限流效果是一样的。
应用级限流
限制总并发/连接/请求数
对于一个应用系统来说，一定会有极限并发/请求数，即总有一个TPS/QPS阈值，如果超了阈值，则系统就会不影响用户请求或响应得非常慢。因此，我们最好进行过载保护，以防止大量请求涌入击垮系统。
如MQ（max_connections）、Redis（tcp-backlog）都会有类似的限制连接数的配置。
限制总资源数
如果有的资源是稀缺资源（如数据库连接、线程），而且可能有多个系统都会去使用它，那么需要加以限制。可以使用池化技术来限制总资源数，如连接池、线程池。假设分配给每个应用的数据库连接是100，那么本应用最多可以使用100个资源，超出则可以等待或者抛异常。
限制某个接口的总并发/请求数
如果接口可能会有并发流量，但又担心访问量太大造成奔溃，那么久需要限制这个接口的总并发/请求数了。因为粒度比较细，可以为每个接口设置相应的阈值。可以使用Java中的AtomicLong或者Semaphore进行限流。Hystrix在信号量模式下也使用Semaphore限制每个接口的总请求数。
一种实现方式如下：
try {
if (atomic.incrementAndGet() > 限流数) {
//拒绝请求
}
//处理请求
} finally {
atomic.decrementAndGet();
}
限制某个接口的时间窗请求数
即限制某个接口/服务每秒/每分钟/每天的请求数/调用量。一种实现方式如下：
LoadingCache
counter =
CacheBuilder.newBuilder()
.expireAfterWrite(2, TimeUnit.SECONDS)
.build(new CacheLoader
() {
@Override
public AtomicLong load(Long aLong) throws Exception {
return new AtomicLong(0);
}
});
long limit = 1000;
while (true) {
long currentSeconds = System.currentTimeMillis() / 1000;
if (counter.get(currentSeconds).incrementAndGet() > limit) {
logger.info("被限流了:{}", currentSeconds);
continue;
}
//业务处理
}
