建站
咨詢
售后
建站咨詢
新聞中心
大家都知道，高并發(fā)系統(tǒng)有三把斧子：緩存、熔斷和限流。但還有一把斧子，經(jīng)常被遺忘在角落里，郁郁不得志，那就是預(yù)熱。
為崗巴等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及崗巴網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都做網(wǎng)站、網(wǎng)站設(shè)計(jì)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、崗巴網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！
現(xiàn)象舉例
先說(shuō)兩個(gè)現(xiàn)象。這些現(xiàn)象，只能在并發(fā)高的系統(tǒng)中出現(xiàn)。
好吧，它已經(jīng)引起了多個(gè)故障。
一、DB重啟后，瞬間死亡
一個(gè)高并發(fā)環(huán)境下的DB，進(jìn)程死亡后進(jìn)行重啟。由于業(yè)務(wù)處在高峰期間，上游的負(fù)載均衡策略發(fā)生了重分配。剛剛啟動(dòng)的DB瞬間接受了1/3的流量，然后load瘋狂飆升，直至再無(wú)響應(yīng)。
原因就是：新啟動(dòng)的DB，各種Cache并沒(méi)有準(zhǔn)備完畢，系統(tǒng)狀態(tài)與正常運(yùn)行時(shí)截然不同?？赡芷匠?/10的量，就能夠把它帶入死亡。
二、服務(wù)重啟后，訪問(wèn)異常
另外一個(gè)常見(jiàn)的問(wèn)題是：我的一臺(tái)服務(wù)器發(fā)生了問(wèn)題，由于負(fù)載均衡的作用，剩下的機(jī)器立馬承載了這些請(qǐng)求，運(yùn)行的很好。當(dāng)服務(wù)重新加入集群時(shí)，卻發(fā)生了大量高耗時(shí)的請(qǐng)求，在請(qǐng)求量高的情況下，甚至大批大批的失敗。
引起的原因大概可以歸結(jié)于：
1、服務(wù)啟動(dòng)后，jvm并未完全準(zhǔn)備完畢，JIT未編譯等。
2、應(yīng)用程序使用的各種資源未準(zhǔn)備就緒。
3、負(fù)載均衡發(fā)生了rebalance。
這兩個(gè)問(wèn)題，都是沒(méi)有做好預(yù)熱
Warm Up，即冷啟動(dòng)/預(yù)熱的方式。當(dāng)系統(tǒng)長(zhǎng)期處于低水位的情況下，流量突然增加時(shí)，直接把系統(tǒng)拉升到高水位可能瞬間把系統(tǒng)壓垮。通過(guò)”冷啟動(dòng)”，讓通過(guò)的流量緩慢增加，在一定時(shí)間內(nèi)逐漸增加到閾值上限，給冷系統(tǒng)一個(gè)預(yù)熱的時(shí)間，避免冷系統(tǒng)被壓垮。
我想要這樣的曲線。
而不是這樣的。
事實(shí)要復(fù)雜的多
流量是不可預(yù)測(cè)的，這不同于自然增長(zhǎng)的流量，或者人為的攻擊——這是一個(gè)從無(wú)到有的過(guò)程。甚至一些自詡超高速的組件，如lmax的disruptor，在這種突然到來(lái)的洪峰之下也會(huì)崩潰。
warmup最合適的切入層面就是網(wǎng)關(guān)。如圖：node4是剛啟動(dòng)的節(jié)點(diǎn)，集成在網(wǎng)關(guān)中的負(fù)載均衡組件，將能夠識(shí)別出這臺(tái)剛加入的實(shí)例，然后逐步放量到這臺(tái)機(jī)器，直到它能夠真正承受高速流量。
假如所有的請(qǐng)求，都經(jīng)過(guò)網(wǎng)關(guān)，一切都好辦的多，也有像Sentinel 之類的組件進(jìn)行切入。但現(xiàn)實(shí)情況往往不能滿足條件。比如：
1、你的應(yīng)用直接獲取了注冊(cè)中心的信息，然后在客戶端組件中進(jìn)行了流量分配。
2、你的應(yīng)用通過(guò)了一些復(fù)雜的中間件和路由規(guī)則，最終定位到某一臺(tái)DB上。
3、你的終端，可能通過(guò)了MQTT協(xié)議，直接連上了MQTT服務(wù)端。
我們進(jìn)行一下抽象，可以看到：所有這些流量分配邏輯，包括網(wǎng)關(guān)，都可以叫做客戶端。即所有的warmup邏輯都是放在客戶端的，它們都與負(fù)載均衡緊密耦合在一起。
解決方式
接口放量
按照以上的分析，通過(guò)編碼手段控制住所有的客戶端調(diào)用，即可解決問(wèn)題。
一個(gè)簡(jiǎn)單的輪詢方式
1、我要能拿到所有要調(diào)用資源的集合，以及啟動(dòng)時(shí)間，冷啟動(dòng)的配置等。
2、給這些資源分配一些權(quán)重，比如最大權(quán)重為100，配置100秒之后冷啟動(dòng)成功。假如現(xiàn)在是第15秒，則總權(quán)重就是100*(n-1)+15。
3、根據(jù)算好的權(quán)重，進(jìn)行分配，流量會(huì)根據(jù)時(shí)間流逝逐步增加，直到與其他節(jié)點(diǎn)等同。
4、一個(gè)極端情況，我的后端只有1個(gè)實(shí)例，根本就啟動(dòng)不起來(lái)。
拿SpringCloud來(lái)說(shuō)，我們就要改變這些組件的行為。
1、ribbon的負(fù)載均衡策略。
2、網(wǎng)關(guān)的負(fù)載均衡策略。
還好，它們都是基礎(chǔ)組件，不用來(lái)回拷貝代碼了。
走馬觀花
顧名思義，意思就是把所有的接口都提前訪問(wèn)一遍，讓系統(tǒng)對(duì)資源進(jìn)行提前準(zhǔn)備。
比如，遍歷所有的http連接，然后發(fā)送請(qǐng)求。
這種方法是部分有效的，一些懶加載的資源會(huì)在這個(gè)階段陸續(xù)加載進(jìn)來(lái)，但不是全部。
JIT等一些增強(qiáng)功能，可能使得預(yù)熱過(guò)程變得非常的長(zhǎng)，走馬觀花的方式，只能在一定程度上有作用。
再比如某些DB，在啟動(dòng)之后，會(huì)執(zhí)行一些非常有特點(diǎn)的sql，使得PageCache里加載到最需要的熱數(shù)據(jù)。
狀態(tài)保留
系統(tǒng)在死亡時(shí)做一個(gè)快照，然后在啟動(dòng)時(shí)，原封不動(dòng)的還原回來(lái)。
這個(gè)過(guò)程就比較魔幻了，因?yàn)橐话愕姆钦ｊP(guān)閉，系統(tǒng)根本沒(méi)有機(jī)會(huì)發(fā)表遺言，所以只能定時(shí)的，在運(yùn)行中的系統(tǒng)中做快照。
節(jié)點(diǎn)在啟動(dòng)時(shí)，再將快照加載到內(nèi)存中。這在一些內(nèi)存型的組件中應(yīng)用廣泛。
通過(guò)比較，我們發(fā)現(xiàn)，最靠譜的方式還是進(jìn)行編碼，將warmup邏輯集成在客戶端。這個(gè)工作可能是痛苦的、漫長(zhǎng)的，但結(jié)局是美好的。
當(dāng)然也可以通過(guò)“摘除nginx->修改權(quán)重->reload nginx”的方式。有時(shí)很有效但不總是有效，通常很放心但不總是放心。
一切隨你。畢竟沒(méi)有前戲直奔主題，那叫魯莽。
本文標(biāo)題：沒(méi)有預(yù)熱，不叫高并發(fā)，叫并發(fā)高
網(wǎng)頁(yè)地址：http://fisionsoft.com.cn/article/coooodp.html
