1、背景
工作中经常会遇到接口需要做并发控制的场景，主要为了在代码层去控制接口负载，避免接口直接过载而不受控制，服务直接拒绝或服务器down机将是我们不想看到的。双11秒杀、其他各种接口服务场景都是服务限流的用武之地。
2、相关概念
QPS
每秒钟处理完请求的次数,衡量单个接口的服务处理能力。
TPS
每秒钟处理完的事务次数,一个事务在分布式处理中，可能会对应多个请求,TPS衡量系统处理事务处理能力。
并发量
系统能同时处理的请求数
RT
响应时间，处理一次请求所需要的平均处理时间
计算关系
QPS = 并发量 / RT
并发量 = QPS * RT
linux系统最大进程数与单进程最大线程数
为了充分了解我们开发的程序服务的负载能力，对于部署程序的linux等系统支持的进程数和线程数应该有所了解。
ps -ef 可以看到Linux系统上启动的进程
ulimit -u查看系统中限制的最大进程数。
ulimit 是一种简单并且有效的实现资源限制的方式。
linux 系统中单个进程的最大线程数有其最大的限制 PTHREAD_THREADS_MAX，这个限制可以在 /usr/include/bits/local_lim.h 中查看，对 linuxthreads 这个值一般是 1024，而NPTL（ Native POSIX Thread Library）中则没有硬性的限制，仅仅受限于系统资源。
流量、带宽
手机流量套餐每月XXX GB 或 xx MB,而能用多少就需要做流量记录和控制。网络流量类似
带宽，去运营商办理网络，100M宽带、50M宽带是带宽区别，带宽一般用位做单位，英文是bit，例如adsl的带宽是2MB，实际上就是2Mbit每秒。
对于微服务来说，对接口做这种类似这种流量的控制目前我没有看到具体应用场景，应该有，有兴趣的童鞋可以自行了解。
web容器并发数
tomcat容器等都有相关的配置参数，提供最大并发数据限制，超过最大并发数参数时，可阻塞最大线程数目配置。
3、限流场景
一般微服务都是分布式部署，有多个实例，选择怎么样的限流策略是需要权衡利弊的。
单机限流
单实例做限流，单个服务多个实例间相互不影响。对于有特定全局限流需求时不适用。
分布式限流
形成整体限流策略，假设3个服务实例，以1s内请求总数n为限流方式（限流方式后续会讲），就是3台机器总体上1s内接口请求的总数之和<=n。分布式限流对限流框架要求更高，技术实现更加复杂。
4、服务限流相关方法
本节参考文章聊聊架构：微服务接口限流的设计与思考
固定时间窗口
x 时间内请求上限数目n 但是由于x时间跨度，导致中间的请求峰值处理并不那么好。某X时间更细单位内请求峰值可能高过请求上限n，导致系统崩溃。
滑动时间窗口
滑动时间窗口算法是对固定时间窗口算法的一种改进，流量经过滑动时间窗口算法整形之后，可以保证任意时间窗口内，都不会超过最大允许的限流值
令牌桶算法
1.接口限制 t 秒内最大访问次数为 n，则每隔 t/n 秒会放一个 token 到桶中； 2.桶中最多可以存放 b 个 token，如果 token 到达时令牌桶已经满了，那么这个 token 会被丢弃； 3.接口请求会先从令牌桶中取 token，拿到 token 则处理接口请求，拿不到 token 则执行限流。
网上有相关的图，非常形象，可以自行搜索。（可以说作者懒，不想加） 令牌桶算法允许某些流量的突发。
参考实现： 1.Google开源工具包Guava提供了限流工具类RateLimiter,该类基于令牌桶算法(Token Bucket)来完成限流。提供平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。 Guava限流
漏桶算法
漏桶算法可以粗略的认为就是注水漏水过程，往桶中以一定速率流出水，以任意速率流入水，当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率
参考实现： 基于Guava-Semaphore—RateLimiter
5、限流过载处理策略
服务降级
考虑是否可以采用优先级阻塞队列（PriorityBlockingQueue）处理服务降级问题。（待验证）
服务拒绝
直接拒绝。
服务告警
与服务监控系统对接，提供告警通知。
服务熔断
犹如股市的熔断机制，惊心动魄。 状态： Closed：熔断器关闭状态，调用失败次数积累，到了阈值（或一定比例）则启动熔断机制； Open：熔断器打开状态，此时对下游的调用都内部直接返回错误，不走网络，但设计了一个时钟选项，默认的时钟达到了一定时间（这个时间一般设置成平均故障处理时间，也就是MTTR），到了这个时间，进入半熔断状态； Half-Open：半熔断状态，允许定量的服务请求，如果调用都成功（或一定比例）则认为恢复了，关闭熔断器，否则认为还没好，又回到熔断器打开状态。 熔断根据某些阈值、条件具有自动恢复能力。 具体实现方式。（待完善）