[[269167]]

大家都知道，高并發系統有三把斧子：緩存、熔斷和限流。但還有一把斧子，經常被遺忘在角落里，郁郁不得志，那就是預熱。

 

現象舉例

先說兩個現象。這些現象，只能在并發高的系統中出現。

好吧，它已經引起了多個故障。

一、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里加載到最需要的熱數據。

狀態保留

系統在死亡時做一個快照，然后在啟動時，原封不動的還原回來。

這個過程就比較魔幻了，因為一般的非正常關閉，系統根本沒有機會發表遺言，所以只能定時的，在運行中的系統中做快照。

節點在啟動時，再將快照加載到內存中。這在一些內存型的組件中應用廣泛。

通過比較，我們發現，最靠譜的方式還是進行編碼，將warmup邏輯集成在客戶端。這個工作可能是痛苦的、漫長的，但結局是美好的。

當然也可以通過“摘除nginx->修改權重->reload nginx”的方式。有時很有效但不總是有效，通常很放心但不總是放心。

一切隨你。畢竟沒有前戲直奔主題，那叫魯莽。