一、流量暴漲的緣由
通常狀況下，引發網站流量暴增大體爲如下兩種狀況
一、不可預測流量（網站被惡意刷量；CDN回源抓取數據；合做業務平臺調取平臺數據等）
二、可預測流量（忽然爆發的社會熱點，營銷活動的宣傳；）web
不論是可預測流量仍是不可預測流量都會表如今帶寬和網站總體架構的應對方案上算法
若是因爲帶寬緣由引發，因爲網站的併發量過高，達到服務器的吞吐極限，致使服務器宕機，這時須要作臨時申請加大帶寬，而後負載均衡分流。
若是因爲外網請求數據庫，致使數據庫頻繁讀寫，數據庫處理能力低，致使大量請求積壓；若是是這種狀況，就須要優化SQL，存儲過程等，若是是請求過大，就要考慮作集羣等。
可預測流量的暴增也會拖慢網頁的打開速度，甚至致使網站服務器宕機。要應對正常流量暴增，在流量高峯期到來以前就能夠適當的調整，通常針對應用服務器的調整能夠防止單點，負載均衡，高可用，增長後端web應用服務器數量，數據庫讀寫分離，拆庫拆表等，防止流量暴增致使服務器掛掉，下面具體說明：數據庫
二、防止流量暴漲預備方案
凡事預則立不預則廢，作任何事情，都要未雨綢繆，若是等到大軍打到家門口，再迎戰就只能被人宰割了。後端
2.一、流量估算
2.二、降級方案
降級總得是用戶能夠買帳的方式才行，不能瞎降。能降級成什麼樣，顯示成什麼樣子，都得預先設計好。UI上有的要配圖，有的要出警告語提示。而做爲後臺服務器，須要有對應的實時開關，一旦設置，馬上進入降級方案。緩存
可是，若是核心服務就是熱點自己，就沒得降級，好比，電商的雙十一，用戶的購買，下單等行爲，下單就是下單，不能下一半，不能砍掉支付，不能隨機性有的能買有的不能買，是涉及到大量寫操做，並且是核心鏈路，沒法降級的，這個時候，限流就比較重要了。服務器
2.二、限流方案
限流的經常使用方式架構
限流的經常使用處理手段有：計數器、滑動窗口、漏桶、令牌。併發
計數器負載均衡
計數器是一種比較簡單的限流算法，用途比較普遍，在接口層面，不少地方使用這種方式限流。在一段時間內，進行計數，與閥值進行比較，到了時間臨界點，將計數器清0。
侷限性：運維
這裏須要注意的是，存在一個時間臨界點的問題。舉個栗子，在12:01:00到12:01:58這段時間內沒有用戶請求，而後在12:01:59這一瞬時發出100個請求，OK，而後在12:02:00這一瞬時又發出了100個請求。這裏你應該能感覺到，在這個臨界點可能會承受惡意用戶的大量請求，甚至超出系統預期的承受。
滑動窗口
因爲計數器存在臨界點缺陷，後來出現了滑動窗口算法來解決。
侷限性：
滑動窗口的意思是說把固定時間片，進行劃分，而且隨着時間的流逝，進行移動，這樣就巧妙的避開了計數器的臨界點問題。也就是說這些固定數量的能夠移動的格子，
將會進行計數判斷閥值，所以格子的數量影響着滑動窗口算法的精度。
漏桶
雖然滑動窗口有效避免了時間臨界點的問題，可是依然有時間片的概念，而漏桶算法在這方面比滑動窗口而言，更加先進。 有一個固定的桶，進水的速率是不肯定的，可是出水的速率是恆定的，當水滿的時候是會溢出的。
令牌桶
注意到，漏桶的出水速度是恆定的，那麼意味着若是瞬時大流量的話，將有大部分請求被丟棄掉（也就是所謂的溢出）。爲了解決這個問題，令牌桶進行了算法改進。
侷限性：
生成令牌的速度是恆定的，而請求去拿令牌是沒有速度限制的。這意味，面對瞬時大流量，該算法能夠在短期內請求拿到大量令牌，並且拿令牌的過程並非消耗很大的事情。（有一點生產令牌，消費令牌的意味） 不管是對於令牌桶拿不到令牌被拒絕，仍是漏桶的水滿了溢出，都是爲了保證大部分流量的正常使用，而犧牲掉了少部分流量，這是合理的，若是由於極少部分流量須要保證的話，那麼就可能致使系統達到極限而掛掉，得不償失。
限流神器：Guava RateLimiter
Guava不只僅在集合、緩存、異步回調等方面功能強大，並且還給咱們封裝好了限流的API！ Guava RateLimiter基於令牌桶算法，咱們只須要告訴RateLimiter系統限制的QPS是多少，那麼RateLimiter將以這個速度往桶裏面放入令牌，而後請求的時候，經過tryAcquire()方法向RateLimiter獲取許可（令牌）。