1、流量暴涨的原因
一般情况下，引起网站流量暴增大致为以下两种情况
1、不可预测流量（网站被恶意刷量；CDN回源抓取数据；合作业务平台调取平台数据等）
2、可预测流量（突然爆发的社会热点，营销活动的宣传；）
不管是可预测流量还是不可预测流量都会表现在带宽和网站整体架构的应对方案上
如果由于带宽原因引起，由于网站的并发量太高，达到服务器的吞吐极限，导致服务器宕机，这时需要做临时申请加大带宽，然后负载均衡分流。
如果由于外网请求数据库，导致数据库频繁读写，数据库处理能力低，导致大量请求积压；如果是这种情况，就需要优化SQL，存储过程等，如果是请求过大，就要考虑做集群等。
可预测流量的暴增也会拖慢网页的打开速度，甚至导致网站服务器宕机。要应对正常流量暴增，在流量高峰期到来之前就可以适当的调整，一般针对应用服务器的调整可以防止单点，负载均衡，高可用，增加后端web应用服务器数量，数据库读写分离，拆库拆表等，防止流量暴增导致服务器挂掉，下面具体说明：
2、防止流量暴涨的预备方案
2.1流量估计
作为一个经验充足的老运维，可以把设计流量*3作为系统压力的下限，即实现完了要压测，压测得到的结果要达到设计流量 * 3（ * 4， * 5都可以），比如服务器在IDC机房，在签合同之前就可以说明当流量异常的时候，提供一定的缓冲带宽，如果是云服务器，可以临时加带宽。
关键是要给系统留些缓冲。一旦发生了什么，不至于挂的太惨。此时，一般会得到一个带缓存的业务服务系统。考虑到缓存高于后台服务2～3个数量级的性能优势，多撑几倍流量一般不成问题。
2.2降级方案
降级总得是用户可以买账的方式才行，不能瞎降。能降级成什么样，显示成什么样子，都得预先设计好。UI上有的要配图，有的要出警告语提示。而作为后台服务器，需要有对应的实时开关，一旦设置，立刻进入降级方案。
但是，如果核心服务就是热点本身，就没得降级，比如，电商的双十一，用户的购买，下单等行为，下单就是下单，不能下一半，不能砍掉支付，不能随机性有的能买有的不能买，是涉及到大量写操作，而且是核心链路，无法降级的，这个时候，限流就比较重要了
2.3限流方案
限流的常用方式
限流的常用处理手段有：计数器、滑动窗口、漏桶、令牌。
1）计数器
计数器是一种比较简单的限流算法，用途比较广泛，在接口层面，很多地方使用这种方式限流。在一段时间内，进行计数，与阀值进行比较，到了时间临界点，将计数器清0。
局限性：
这里需要注意的是，存在一个时间临界点的问题。举个栗子，在12:01:00到12:01:58这段时间内没有用户请求，然后在12:01:59这一瞬时发出100个请求，OK，然后在12:02:00这一瞬时又发出了100个请求。这里你应该能感受到，在这个临界点可能会承受恶意用户的大量请求，甚至超出系统预期的承受。
2）滑动窗口
由于计数器存在临界点缺陷，后来出现了滑动窗口算法来解决
局限性：
滑动窗口的意思是说把固定时间片，进行划分，并且随着时间的流逝，进行移动，这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子， 将会进行计数判断阀值，因此格子的数量影响着滑动窗口算法的精度
3）漏桶
虽然滑动窗口有效避免了时间临界点的问题，但是依然有时间片的概念，而漏桶算法在这方面比滑动窗口而言，更加先进。 有一个固定的桶，进水的速率是不确定的，但是出水的速率是恒定的，当水满的时候是会溢出的。
4）令牌桶
注意到，漏桶的出水速度是恒定的，那么意味着如果瞬时大流量的话，将有大部分请求被丢弃掉（也就是所谓的溢出）。为了解决这个问题，令牌桶进行了算法改进。
局限性：
生成令牌的速度是恒定的，而请求去拿令牌是没有速度限制的。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。（有一点生产令牌，消费令牌的意味） 不论是对于令牌桶拿不到令牌被拒绝，还是漏桶的水满了溢出，都是为了保证大部分流量的正常使用，而牺牲掉了少部分流量，这是合理的，如果因为极少部分流量需要保证的话，那么就可能导致系统达到极限而挂掉，得不偿失。
5）限流神器：Guava RateLimiter
Guava不仅仅在集合、缓存、异步回调等方面功能强大，而且还给我们封装好了限流的API！ Guava RateLimiter基于令牌桶算法，我们只需要告诉RateLimiter系统限制的QPS是多少，那么RateLimiter将以这个速度往桶里面放入令牌，然后请求的时候，通过tryAcquire()方法向RateLimiter获取许可（令牌）。
