开发访问量比较大的系统是，爬虫的目的就是解决访问量大的问题；缓存穿透是为了保护后端数据库查询服务；计数服务解决了接近真实访问量以及数据库服务的压力。
架构图
限流
就拿十万博客来说，如果存在热点文章，可能会有数十万级别的并发用户参与阅读。如果想让这些用户正常访问，无非就是加机器横向扩展各种服务，但凡事都有一个利益平衡点，有时候只需要少量的机器保证大部分用户在大部分时间可以正常访问即可。
亦或是，如果存在大量爬虫或者恶意攻击，我们必须采取一定的措施来保证服务的正常运行。这时候我们就要考虑限流来保证服务的可用性，以防止非预期的请求对系统压力过大而引起的系统瘫痪。通常的策略就是拒绝多余的访问，或者让多余的访问排队等待服务。
限流算法
任何限流都不是漫无目的的，也不是一个开关就可以解决的问题，常用的限流算法有：令牌桶，漏桶。
令牌桶
令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送(百科)。
用户的请求速率是不固定的，这里我们假定为10r/s，令牌按照5个每秒的速率放入令牌桶，桶中最多存放20个令牌。仔细想想，是不是总有那么一部分请求被丢弃。
漏桶
漏桶算法的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量(百科)。
令牌桶是无论你流入速率多大，我都按照既定的速率去处理，如果桶满则拒绝服务。
应用限流
Tomcat
在Tomcat容器中，我们可以通过自定义线程池，配置最大连接数，请求处理队列等参数来达到限流的目的。
Tomcat默认使用自带的连接池，这里我们也可以自定义实现，打开/conf/server.xml文件，在Connector之前配置一个线程池：
-
name：共享线程池的名字。这是Connector为了共享线程池要引用的名字，该名字必须唯一。默认值：None；
-
namePrefix:在JVM上，每个运行线程都可以有一个name 字符串。这一属性为线程池中每个线程的name字符串设置了一个前缀，Tomcat将把线程号追加到这一前缀的后面。默认值：tomcat-exec-；
-
maxThreads：该线程池可以容纳的最大线程数。默认值：200；
-
maxIdleTime：在Tomcat关闭一个空闲线程之前，允许空闲线程持续的时间(以毫秒为单位)。只有当前活跃的线程数大于minSpareThread的值，才会关闭空闲线程。默认值：60000(一分钟)。
-
minSpareThreads：Tomcat应该始终打开的最小不活跃线程数。默认值：25。
配置Connector
-
executor：表示使用该参数值对应的线程池；
-
minProcessors：服务器启动时创建的处理请求的线程数；
-
maxProcessors：最大可以创建的处理请求的线程数；
-
acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。
API限流
这里我们采用开源工具包guava提供的限流工具类RateLimiter进行API限流，该类基于"令牌桶算法"，开箱即用。
自定义定义注解
自定义切面
业务实现：
分布式限流
Nginx
如何使用Nginx实现基本的限流，比如单个IP限制每秒访问50次。通过Nginx限流模块，我们可以设置一旦并发连接数超过我们的设置，将返回503错误给客户端。
配置nginx.conf
配置说明
imitconnzone
是针对每个IP定义一个存储session状态的容器。这个示例中定义了一个100m的容器，按照32bytes/session，可以处理3200000个session。
limit_rate 300k;
对每个连接限速300k. 注意，这里是对连接限速，而不是对IP限速。如果一个IP允许两个并发连接，那么这个IP就是限速limit_rate×2。
burst=5；
这相当于桶的大小，如果某个请求超过了系统处理速度，会被放入桶中，等待被处理。如果桶满了，那么抱歉，请求直接返回503，客户端得到一个服务器忙的响应。如果系统处理请求的速度比较慢，桶里的请求也不能一直待在里面，如果超过一定时间，也是会被直接退回，返回服务器忙的响应。
OpenResty
这里我们使用 OpenResty 开源的限流方案，测试案例使用OpenResty1.15.8.1最新版本，自带lua-resty-limit-traffic模块以及案例 ，实现起来更为方便。
限制接口总并发数/请求数
热点博文，由于突发流量暴增，有可能会影响整个系统的稳定性从而造成崩溃，这时候我们就要限制热点博文的总并发数/请求数。
这里我们采用 lua-resty-limit-traffic中的resty.limit.count模块实现：
限制接口时间窗请求数
现在网络爬虫泛滥，有时候并不是人为的去点击，亦或是存在恶意攻击的情况。此时我们就要对客户端单位时间内的请求数进行限制，以至于黑客不是那么猖獗。当然了道高一尺魔高一丈，攻击者总是会有办法绕开你的防线，从另一方面讲也促进了技术的进步。
这里我们采用 lua-resty-limit-traffic中的resty.limit.conn模块实现：
平滑限制接口请求数
之前的限流方式允许突发流量，也就是说瞬时流量都会被允许。突然流量如果不加以限制会影响整个系统的稳定性，因此在秒杀场景中需要对请求整形为平均速率处理，即20r/s。
这里我们采用 lua-resty-limit-traffic 中的resty.limit.req 模块实现漏桶限流和令牌桶限流。
其实漏桶和令牌桶根本的区别就是，如何处理超过请求速率的请求。漏桶会把请求放入队列中去等待均速处理，队列满则拒绝服务；令牌桶在桶容量允许的情况下直接处理这些突发请求。
漏桶
桶容量大于零，并且是延迟模式。如果桶没满，则进入请求队列以固定速率等待处理，否则请求被拒绝。
令牌桶
桶容量大于零，并且是非延迟模式。如果桶中存在令牌，则允许突发流量，否则请求被拒绝。
压测
为了测试以上配置效果，我们采用AB压测，Linux下执行以下命令即可：
测试命令：
测试结果：
总结
以上限流方案，只是针对此次大访问量项目做一个简单的小结，大家也不要刻意区分那种方案的好坏，只要适合业务场景就是最好的。
