[[269167]]

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

現(xiàn)象舉例

先說兩個現(xiàn)象。這些現(xiàn)象，只能在并發(fā)高的系統(tǒng)中出現(xiàn)。

好吧，它已經(jīng)引起了多個故障。

一、DB重啟后，瞬間死亡

一個高并發(fā)環(huán)境下的DB，進程死亡后進行重啟。由于業(yè)務(wù)處在高峰期間，上游的負(fù)載均衡策略發(fā)生了重分配。剛剛啟動的DB瞬間接受了1/3的流量，然后load瘋狂飆升，直至再無響應(yīng)。

原因就是：新啟動的DB，各種Cache并沒有準(zhǔn)備完畢，系統(tǒng)狀態(tài)與正常運行時截然不同?？赡芷匠?/10的量，就能夠把它帶入死亡。

二、服務(wù)重啟后，訪問異常

另外一個常見的問題是：我的一臺服務(wù)器發(fā)生了問題，由于負(fù)載均衡的作用，剩下的機器立馬承載了這些請求，運行的很好。當(dāng)服務(wù)重新加入集群時，卻發(fā)生了大量高耗時的請求，在請求量高的情況下，甚至大批大批的失敗。

引起的原因大概可以歸結(jié)于：

1、服務(wù)啟動后，jvm并未完全準(zhǔn)備完畢，JIT未編譯等。

2、應(yīng)用程序使用的各種資源未準(zhǔn)備就緒。

3、負(fù)載均衡發(fā)生了rebalance。

這兩個問題，都是沒有做好預(yù)熱

Warm Up，即冷啟動/預(yù)熱的方式。當(dāng)系統(tǒng)長期處于低水位的情況下，流量突然增加時，直接把系統(tǒng)拉升到高水位可能瞬間把系統(tǒng)壓垮。通過”冷啟動”，讓通過的流量緩慢增加，在一定時間內(nèi)逐漸增加到閾值上限，給冷系統(tǒng)一個預(yù)熱的時間，避免冷系統(tǒng)被壓垮。

我想要這樣的曲線。

而不是這樣的。

事實要復(fù)雜的多

流量是不可預(yù)測的，這不同于自然增長的流量，或者人為的攻擊——這是一個從無到有的過程。甚至一些自詡超高速的組件，如lmax的disruptor，在這種突然到來的洪峰之下也會崩潰。

warmup最合適的切入層面就是網(wǎng)關(guān)。如圖：node4是剛啟動的節(jié)點，集成在網(wǎng)關(guān)中的負(fù)載均衡組件，將能夠識別出這臺剛加入的實例，然后逐步放量到這臺機器，直到它能夠真正承受高速流量。

假如所有的請求，都經(jīng)過網(wǎng)關(guān)，一切都好辦的多，也有像Sentinel 之類的組件進行切入。但現(xiàn)實情況往往不能滿足條件。比如：

1、你的應(yīng)用直接獲取了注冊中心的信息，然后在客戶端組件中進行了流量分配。

2、你的應(yīng)用通過了一些復(fù)雜的中間件和路由規(guī)則，最終定位到某一臺DB上。

3、你的終端，可能通過了MQTT協(xié)議，直接連上了MQTT服務(wù)端。

我們進行一下抽象，可以看到：所有這些流量分配邏輯，包括網(wǎng)關(guān)，都可以叫做客戶端。即所有的warmup邏輯都是放在客戶端的，它們都與負(fù)載均衡緊密耦合在一起。

解決方式

接口放量

按照以上的分析，通過編碼手段控制住所有的客戶端調(diào)用，即可解決問題。

一個簡單的輪詢方式

1、我要能拿到所有要調(diào)用資源的集合，以及啟動時間，冷啟動的配置等。

2、給這些資源分配一些權(quán)重，比如最大權(quán)重為100，配置100秒之后冷啟動成功。假如現(xiàn)在是第15秒，則總權(quán)重就是100*(n-1)+15。

3、根據(jù)算好的權(quán)重，進行分配，流量會根據(jù)時間流逝逐步增加，直到與其他節(jié)點等同。

4、一個極端情況，我的后端只有1個實例，根本就啟動不起來。

拿SpringCloud來說，我們就要改變這些組件的行為。

1、ribbon的負(fù)載均衡策略。

2、網(wǎng)關(guān)的負(fù)載均衡策略。

還好，它們都是基礎(chǔ)組件，不用來回拷貝代碼了。

走馬觀花

顧名思義，意思就是把所有的接口都提前訪問一遍，讓系統(tǒng)對資源進行提前準(zhǔn)備。

比如，遍歷所有的http連接，然后發(fā)送請求。

這種方法是部分有效的，一些懶加載的資源會在這個階段陸續(xù)加載進來，但不是全部。

JIT等一些增強功能，可能使得預(yù)熱過程變得非常的長，走馬觀花的方式，只能在一定程度上有作用。

再比如某些DB，在啟動之后，會執(zhí)行一些非常有特點的sql，使得PageCache里加載到最需要的熱數(shù)據(jù)。

狀態(tài)保留

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

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

節(jié)點在啟動時，再將快照加載到內(nèi)存中。這在一些內(nèi)存型的組件中應(yīng)用廣泛。

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

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

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