前言

在实际项目中，曾经遭遇过线上5W+QPS的峰值，也在压测状态下经历过10W+QPS的大流量请求，本篇博客的话题主要就是自己对高并发流量控制的一点思考。

应对大流量的一些思路

首先，我们来说一下什么是大流量？

大流量，我们很可能会冒出：TPS（每秒事务量），QPS（每秒请求量），1W+，5W+，10W+，100W+...。其实并没有一个绝对的数字，如果这个量造成了系统的压力，影响了系统的性能，那么这个量就可以称之为大流量了。

其次，应对大流量的一些常见手段是什么？

缓存：说白了，就是让数据尽早进入缓存，离程序近一点，不要大量频繁的访问DB。

降级：如果不是核心链路，那么就把这个服务降级掉。打个比喻，现在的APP都讲究千人千面，拿到数据后，做个性化排序展示，如果在大流量下，这个排序就可以降级掉！

限流：大家都知道，北京地铁早高峰，地铁站都会做一件事情，就是限流了！想法很直接，就是想在一定时间内把请求限制在一定范围内，保证系统不被冲垮，同时尽可能提升系统的吞吐量。

注意到，有些时候，缓存和降级是解决不了问题的，比如，电商的双十一，用户的购买，下单等行为，是涉及到大量写操作，而且是核心链路，无法降级的，这个时候，限流就比较重要了。

那么接下来，我们重点说一下，限流。

限流的常用方式

限流的常用处理手段有：计数器、滑动窗口、漏桶、令牌。

计数器

计数器是一种比较简单的限流算法，用途比较广泛，在接口层面，很多地方使用这种方式限流。在一段时间内，进行计数，与阀值进行比较，到了时间临界点，将计数器清0。

代码实例

这里需要注意的是，存在一个时间临界点的问题。举个栗子，在12:01:00到12:01:58这段时间内没有用户请求，然后在12:01:59这一瞬时发出100个请求，OK，然后在12:02:00这一瞬时又发出了100个请求。这里你应该能感受到，在这个临界点可能会承受恶意用户的大量请求，甚至超出系统预期的承受。

滑动窗口

由于计数器存在临界点缺陷，后来出现了滑动窗口算法来解决。

滑动窗口的意思是说把固定时间片，进行划分，并且随着时间的流逝，进行移动，这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子，将会进行计数判断阀值，因此格子的数量影响着滑动窗口算法的精度。

漏桶

虽然滑动窗口有效避免了时间临界点的问题，但是依然有时间片的概念，而漏桶算法在这方面比滑动窗口而言，更加先进。

有一个固定的桶，进水的速率是不确定的，但是出水的速率是恒定的，当水满的时候是会溢出的。

代码实现

令牌桶

注意到，漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。为了解决这个问题，令牌桶进行了算法改进。

生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。（有一点生产令牌，消费令牌的意味）

不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量，这是合理的，如果因为极少部分流量需要保证的话，那么就可能导致系统达到极限而挂掉，得不偿失。

代码实现

限流神器：Guava RateLimiter

Guava不仅仅在集合、缓存、异步回调等方面功能强大（可以参考博主的《使用Google Guava快乐编程》），而且还给我们封装好了限流的API！

Guava RateLimiter基于令牌桶算法，我们只需要告诉RateLimiter系统限制的QPS是多少，那么RateLimiter将以这个速度往桶里面放入令牌，然后请求的时候，通过tryAcquire()方法向RateLimiter获取许可（令牌）。

代码示例

分布式场景下的限流

上面所说的限流的一些方式，都是针对单机而言的，其实大部分的场景，单机的限流已经足够了。分布式下限流的手段常常需要多种技术相结合，比如Nginx+Lua，Redis+Lua等去做。本文主要讨论的是单机的限流，这里就不在详细介绍分布式场景下的限流了。

一句话，让系统的流量，先到队列中排队、限流，不要让流量直接打到系统上。

好了，到这里，本文就结束了！

早安！

美好的一天开始了，上班咯！

手写系列相关爆文

【手写系列】写出我的第一个框架：迷你版Spring MVC

【手写系列】透彻理解Spring事务设计思想之手写实现

【手写系列】透彻理解MyBatis设计思想之手写实现

【手写系列】纯手写实现一个高可用的RPC

【手写系列】理解数据库连接池底层原理之手写实现

【手写系列】对HashMap的思考及手写实现

【手写系列】纯手写实现JDK动态代理

【手写系列】写一个迷你版的Tomcat

作者：张丰哲
链接：https://www.jianshu.com/p/d9504fc0af4d
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

对高并发流量控制的一点思考相关推荐

对高并发流量控制的一点思考推荐
前言在实际项目中,曾经遭遇过线上5W+QPS的峰值,也在压测状态下经历过10W+QPS的大流量请求,本篇博客的话题主要就是自己对高并发流量控制的一点思考. 应对大流量的一些思路首先,我们来说一下什 ...
高并发流量控制与算法实现思路
高并发流量控制与算法实现思路前言昨天看了一篇关于高并发流量控制的文章,感觉对我启发非常的大,所以写一篇记录总结一下,方便于以后我自己的学习与复盘. 简介首先要知道什么是大流量听到大流量 ...
中国铁路 12306 网站的高并发架构带来的思考？研究分析后，果然超牛逼…
>>号外:关注"Java精选"公众号,菜单栏->聚合->干货分享,回复关键词领取视频资料.开源项目. 12306 抢票,极限并发带来的思考虽然现在大多数情 ...
关于健康吗、核算检测等系统高并发问题的一些思考
针对****.****系统出现并发性等问题,总结了一下自己的想法,在需求方面,梳理了以下三个点: (1)在一个页面展示某个人的健康(吗)状态和最近若干次的核(算)检测结果,每个人的健康(吗)状态由大数 ...
关于php 高并发解决的一点思路
涉及抢购.秒杀.抽奖.抢票等活动时,为了避免超卖,那么库存数量是有限的,但是如果同时下单人数超过了库存数量,就会导致商品超卖问题.那么我们怎么来解决这个问题呢,我的思路如下(伪代码): sql1:查询 ...
高并发高可用系统的常见应对策略
解耦神器:MQ MQ是分布式架构中的解耦神器,应用非常普遍.有些分布式事务也是利用MQ来做的.由于其高吞吐量,在一些业务比较复杂的情况,可以先做基本的数据验证,然后将数据放入MQ,由消费者异步去处理后 ...
高并发高可用系统的常见应对策略秒杀等-(阿里)
对于一个需要处理高并发的系统而言,可以从多个层面去解决这个问题. 1.数据库系统:数据库系统可以采取集群策略以保证某台数据库服务器的宕机不会影响整个系统,并且通过负载均衡策略来降低每一台数据库服务器的 ...
高并发高可用系统应对策略的一些思考
为什么80%的码农都做不了架构师?>>> 解耦神器:MQ MQ是分布式架构中的解耦神器,应用非常普遍.有些分布式事务也是利用MQ来做的.由于其高吞吐量,在一些业务比较复杂的情况 ...
高并发高可靠性系统思考1
CPU不是瓶颈,网络才是: 墨菲定律:任何事情都没表面看起来那么简单:会出错的总会出错: 可靠性: 集群:无状态集群:有状态集群,很难处理,尽量剥离出状态部分做集中式部署,其他做无状态部署: mate ...

对高并发流量控制的一点思考

前言