沒有預熱，這不叫高並發，叫並發高
大家都知道，高並發系統有三把斧子：緩存、熔斷和限流。但還有一把斧子，經常被遺忘在角落裡，鬱鬱不得志，那就是預熱。
現象舉例
先說兩個現象。這些現象，只能在並發高的系統中出現。
好吧，它已經引起了多個故障。
一、DB重啟後，瞬間死亡
一個高並發環境下的DB，進程死亡後進行重啟。由於業務處在高峯期間，上游的負載均衡策略發生了重分配。剛剛啟動的DB瞬間接受了1/3的流量，然後load瘋狂飆升，直至再無響應。
原因就是：新啟動的DB，各種Cache並沒有準備完畢，系統狀態與正常運行時截然不同。可能平常1/10的量，就能夠把它帶入死亡。
二、服務重啟後，訪問異常
另外一個常見的問題是：我的一臺伺服器發生了問題，由於負載均衡的作用，剩下的機器立馬承載了這些請求，運行的很好。當服務重新加入集羣時，卻發生了大量高耗時的請求，在請求量高的情況下，甚至大批大批的失敗。
引起的原因大概可以歸結於：
1、服務啟動後，jvm並未完全準備完畢，JIT未編譯等。
2、應用程序使用的各種資源未準備就緒。
3、負載均衡發生了rebalance。
這兩個問題，都是沒有做好預熱
Warm Up，即冷啟動/預熱的方式。當系統長期處於低水位的情況下，流量突然增加時，直接把系統拉昇到高水位可能瞬間把系統壓垮。通過」冷啟動」，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。
我想要這樣的曲線。
而不是這樣的。
事實要複雜的多
流量是不可預測的，這不同於自然增長的流量，或者人為的攻擊——這是一個從無到有的過程。甚至一些自詡超高速的組件，如lmax的disruptor，在這種突然到來的洪峯之下也會崩潰。
warmup最合適的切入層面就是網關。如圖：node4是剛啟動的節點，集成在網關中的負載均衡組件，將能夠識別出這臺剛加入的實例，然後逐步放量到這臺機器，直到它能夠真正承受高速流量。
假如所有的請求，都經過網關，一切都好辦的多，也有像Sentinel 之類的組件進行切入。但現實情況往往不能滿足條件。比如：
1、你的應用直接獲取了註冊中心的信息，然後在客戶端組件中進行了流量分配。
2、你的應用通過了一些複雜的中間件和路由規則，最終定位到某一臺DB上。
3、你的終端，可能通過了MQTT協議，直接連上了MQTT服務端。
我們進行一下抽象，可以看到：所有這些流量分配邏輯，包括網關，都可以叫做客戶端。即所有的warmup邏輯都是放在客戶端的，它們都與負載均衡緊密耦合在一起。
解決方式
介面放量
按照以上的分析，通過編碼手段控制住所有的客戶端調用，即可解決問題。
一個簡單的輪詢方式
1、我要能拿到所有要調用資源的集合，以及啟動時間，冷啟動的配置等。
2、給這些資源分配一些權重，比如最大權重為100，配置100秒之後冷啟動成功。假如現在是第15秒，則總權重就是100*(n-1)+15。
3、根據算好的權重，進行分配，流量會根據時間流逝逐步增加，直到與其他節點等同。
4、一個極端情況，我的後端只有1個實例，根本就啟動不起來。
拿SpringCloud來說，我們就要改變這些組件的行為。
1、ribbon的負載均衡策略。
2、網關的負載均衡策略。
還好，它們都是基礎組件，不用來回拷貝代碼了。
走馬觀花
顧名思義，意思就是把所有的介面都提前訪問一遍，讓系統對資源進行提前準備。
比如，遍歷所有的http連接，然後發送請求。
這種方法是部分有效的，一些懶載入的資源會在這個階段陸續載入進來，但不是全部。
JIT等一些增強功能，可能使得預熱過程變得非常的長，走馬觀花的方式，只能在一定程度上有作用。
再比如某些DB，在啟動之後，會執行一些非常有特點的sql，使得PageCache裏載入到最需要的熱數據。
狀態保留
系統在死亡時做一個快照，然後在啟動時，原封不動的還原回來。
這個過程就比較魔幻了，因為一般的非正常關閉，系統根本沒有機會發表遺言，所以只能定時的，在運行中的系統中做快照。
節點在啟動時，再將快照載入到內存中。這在一些內存型的組件中應用廣泛。
End
通過比較，我們發現，最靠譜的方式還是進行編碼，將warmup邏輯集成在客戶端。這個工作可能是痛苦的、漫長的，但結局是美好的。
當然也可以通過「摘除nginx->修改權重->reload nginx」的方式。有時很有效但不總是有效，通常很放心但不總是放心。
一切隨你。畢竟沒有前戲直奔主題，那叫魯莽。
推薦閱讀：
