为了上班方便，去年我把自己在北郊的房子租出去了，搬到了南郊，这样离我上班的地方就近了，它为我节约了很多的时间成本，我可以用它来做很多有意义的事，最起码不会因为堵车而闹心了，幸福感直线上升。
但即使这样，生活也有其他的烦恼。南郊的居住密度比较大，因此停车就成了头痛的事，我租的是路两边的非固定车位，每次只要下班回来，一定是没有车位停了，因此我只能和别人的车并排停着，但这样带来的问题是，我每天早上都要被挪车的电话给叫醒，心情自然就不用说了。
但后来几天，我就慢慢变聪明了，我头天晚上停车的时候，会找第二天限行的车并排停着，这样我第二天就不用挪车了，这真是限行给我带来的“巨大红利”啊。
而车辆限行就是一种生活中很常见的限流策略，他除了给我带来了以上的好处之外，还给我们美好的生活环境带来了一丝改善，并且快速增长的私家车已经给我们的交通带来了巨大的“负担”，如果再不限行，可能所有的车都要被堵在路上，这就是限流给我们的生活带来的巨大好处。
从生活回到程序中，假设一个系统只能为 10W 人提供服务，突然有一天因为某个热点事件，造成了系统短时间内的访问量迅速增加到了 50W，那么导致的直接结果是系统崩溃，任何人都不能用系统了，显然只有少人数能用远比所有人都不能用更符合我们的预期，因此这个时候我们要使用「限流」了。
限流分类限流的实现方案有很多种，磊哥这里稍微理了一下，限流的分类如下所示：
合法性验证限流：比如验证码、IP 黑名单等，这些手段可以有效的防止恶意攻击和爬虫采集；
容器限流：比如 Tomcat、Nginx 等限流手段，其中 Tomcat 可以设置最大线程数（maxThreads），当并发超过最大线程数会排队等待执行；而 Nginx 提供了两种限流手段：一是控制速率，二是控制并发连接数；
服务端限流：比如我们在服务器端通过限流算法实现限流，此项也是我们本文介绍的重点。
合法性验证限流为最常规的业务代码，就是普通的验证码和 IP 黑名单系统，本文就不做过多的叙述了，我们重点来看下后两种限流的实现方案：容器限流和服务端限流。
容器限流 Tomcat 限流Tomcat 8.5 版本的最大线程数在 conf/server.xml 配置中，如下所示：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" maxThreads="150" redirectPort="8443" />其中 maxThreads 就是 Tomcat 的最大线程数，当请求的并发大于此值（maxThreads）时，请求就会排队执行，这样就完成了限流的目的。
小贴士：maxThreads 的值可以适当的调大一些，此值默认为 150（Tomcat 版本 8.5.42），但这个值也不是越大越好，要看具体的硬件配置，需要注意的是每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用，并且线程越多 GC 的负担也越重。最后需要注意一下，操作系统对于进程中的线程数有一定的限制，Windows 每个进程中的线程数不允许超过 2000，Linux 每个进程中的线程数不允许超过 1000。
Nginx 限流Nginx 提供了两种限流手段：一是控制速率，二是控制并发连接数。
控制速率我们需要使用 limit_req_zone 用来限制单位时间内的请求数，即速率限制，示例配置如下：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s; server { location / { limit_req zone=mylimit; } }以上配置表示，限制每个 IP 访问的速度为 2r/s，因为 Nginx 的限流统计是基于毫秒的，我们设置的速度是 2r/s，转换一下就是 500ms 内单个 IP 只允许通过 1 个请求，从 501ms 开始才允许通过第 2 个请求。
我们使用单 IP 在 10ms 内发并发送了 6 个请求的执行结果如下：
从以上结果可以看出他的执行符合我们的预期，只有 1 个执行成功了，其他的 5 个被拒绝了（第 2 个在 501ms 才会被正常执行）。
速率限制升级版
上面的速率控制虽然很精准但是应用于真实环境未免太苛刻了，真实情况下我们应该控制一个 IP 单位总时间内的总访问次数，而不是像上面那么精确但毫秒，我们可以使用 burst 关键字开启此设置，示例配置如下：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s; server { location / { limit_req zone=mylimit burst=4; } }burst=4 表示每个 IP 最多允许4个突发请求，如果单个 IP 在 10ms 内发送 6 次请求的结果如下：
从以上结果可以看出，有 1 个请求被立即处理了，4 个请求被放到 burst 队列里排队执行了，另外 1 个请求被拒绝了。
控制并发数