如果流量突然飆大，總有一個資源會遇到瓶頸。按照經驗大概出問題地方是DB，磁盤io、CPU、帶寬、連接數、內存其中的一個或幾個。不同的業務，不同的系統設計，出問題的地方會有所不同。如果流量增大數倍，勢必某個資源會在瞬間被榨干，然后所有的服務都會“開小差”，引起用戶的抱怨。而解決問題的關鍵，是在問題發生時，盡量減少出問題的資源被訪問。
1、流量暴漲的原因
一般情況下，引起網站流量暴增大致為以下兩種情況
1、不可預測流量（網站被惡意刷量；CDN回源抓取數據；合作業務平台調取平台數據等）
2、可預測流量（突然爆發的社會熱點，營銷活動的宣傳；）
不管是可預測流量還是不可預測流量都會表現在帶寬和網站整體架構的應對方案上
如果由於帶寬原因引起，由於網站的並發量太高，達到服務器的吞吐極限，導致服務器宕機，這時需要做臨時申請加大帶寬，然后負載均衡分流。
如果由於外網請求數據庫，導致數據庫頻繁讀寫，數據庫處理能力低，導致大量請求積壓；如果是這種情況，就需要優化SQL，存儲過程等，如果是請求過大，就要考慮做集群等。
可預測流量的暴增也會拖慢網頁的打開速度，甚至導致網站服務器宕機。要應對正常流量暴增，在流量高峰期到來之前就可以適當的調整，一般針對應用服務器的調整可以防止單點，負載均衡，高可用，增加后端web應用服務器數量，數據庫讀寫分離，拆庫拆表等，防止流量暴增導致服務器掛掉，下面具體說明：
2、防止流量暴漲預備方案
凡事預則立不預則廢，做任何事情，都要未雨綢繆，如果等到大軍打到家門口，再迎戰就只能被人宰割了。
2.1、流量估算
作為一個經驗充足的老運維，可以把設計流量*3作為系統壓力的下限，即實現完了要壓測，壓測得到的結果要達到設計流量 * 3（ * 4， * 5都可以），比如服務器在IDC機房，在簽合同之前就可以說明當流量異常的時候，提供一定的緩沖帶寬，如果是雲服務器，可以臨時加帶寬。
關鍵是要給系統留些緩沖。一旦發生了什么，不至於掛的太慘。此時，一般會得到一個帶緩存的業務服務系統。考慮到緩存高於后台服務2～3個數量級的性能優勢，多撐幾倍流量一般不成問題。
2.2、降級方案
降級總得是用戶可以買賬的方式才行，不能瞎降。能降級成什么樣，顯示成什么樣子，都得預先設計好。UI上有的要配圖，有的要出警告語提示。而作為后台服務器，需要有對應的實時開關，一旦設置，立刻進入降級方案。
但是，如果核心服務就是熱點本身，就沒得降級，比如，電商的雙十一，用戶的購買，下單等行為，下單就是下單，不能下一半，不能砍掉支付，不能隨機性有的能買有的不能買，是涉及到大量寫操作，而且是核心鏈路，無法降級的，這個時候，限流就比較重要了。
2.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獲取許可（令牌）