(資料圖)

1.停電事故后電力恢復(fù)的方式

1.1.停電后常見的情形是，送電幾秒鐘后又再次斷電

1.2.數(shù)百萬臺(tái)空調(diào)和冰箱的用電需求，使剛剛恢復(fù)的電力供應(yīng)發(fā)生過載

1.3.當(dāng)電力供應(yīng)不足時(shí)，增加的電流很快就到達(dá)滿負(fù)荷，導(dǎo)致過載，觸發(fā)斷路器跳閘，燈再次熄滅

2.經(jīng)驗(yàn)教訓(xùn)

2.1.系統(tǒng)規(guī)模相對(duì)較小的組件子集上永遠(yuǎn)不會(huì)出現(xiàn)這種情況

2.2.系統(tǒng)達(dá)到穩(wěn)態(tài)時(shí)的負(fù)載，會(huì)與系統(tǒng)啟動(dòng)或周期性運(yùn)行的負(fù)載存在明顯不同

2.3.示例

2.3.1.一個(gè)應(yīng)用程序服務(wù)器農(nóng)場(chǎng)的啟動(dòng)過程

2.3.2.每臺(tái)服務(wù)器都需要連接到數(shù)據(jù)庫(kù)，并加載一定數(shù)量的參考數(shù)據(jù)或種子數(shù)據(jù)

2.3.3.每臺(tái)服務(wù)器的緩存都從空閑狀態(tài)開始，逐漸形成一個(gè)有用的工作集

2.3.4.大多數(shù)HTTP請(qǐng)求會(huì)轉(zhuǎn)換為一個(gè)或多個(gè)數(shù)據(jù)庫(kù)查詢

2.3.5.當(dāng)應(yīng)用程序啟動(dòng)時(shí)，數(shù)據(jù)庫(kù)上的瞬時(shí)負(fù)載要比運(yùn)行一段時(shí)間后的負(fù)載高得多

3.一窩蜂

3.1.一堆服務(wù)器一同對(duì)數(shù)據(jù)庫(kù)施加瞬時(shí)負(fù)載

3.2.是對(duì)系統(tǒng)的集中使用，相比將峰值流量分散開后所需的系統(tǒng)能力，一窩蜂需要一個(gè)更高的系統(tǒng)容量峰值

3.3.一窩蜂所需系統(tǒng)成本過高，高峰需求無法處理

3.4.引發(fā)一窩蜂現(xiàn)象的情況

3.4.1.在代碼升級(jí)和重新運(yùn)行之后，啟動(dòng)多臺(tái)服務(wù)器

3.4.2.午夜（或任何一個(gè)整點(diǎn)時(shí)間）觸發(fā)cron作業(yè)

3.4.3.配置管理系統(tǒng)推出變更

3.4.4.當(dāng)一些外部現(xiàn)象引起流量的同步“脈沖”時(shí)

3.4.5.阻塞許多線程的所有地方，它們?cè)诘却硞€(gè)線程完成工作

3.4.5.1.這個(gè)狀態(tài)打破時(shí)，新釋放的線程就會(huì)對(duì)任何接收數(shù)據(jù)包的下游系統(tǒng)施加一窩蜂

3.4.6.虛擬用戶的腳本存在固定等待時(shí)間，則在進(jìn)行負(fù)載測(cè)試時(shí)，就會(huì)產(chǎn)生流量脈沖

3.4.6.1.腳本中的每個(gè)等待時(shí)間都應(yīng)該附帶一個(gè)小的隨機(jī)時(shí)間增量

3.5.解決方案

3.5.1.使用增加的退避時(shí)間避免脈沖

3.5.1.1.固定的重試時(shí)間間隔，會(huì)集中那段時(shí)間的調(diào)用方需求

3.5.1.2.使用退避算法，不同調(diào)用方在經(jīng)過自己的退避時(shí)間后，在不同的時(shí)間點(diǎn)發(fā)起調(diào)用

3.5.2.使用隨機(jī)時(shí)鐘擺動(dòng)以分散需求

3.5.2.1.不要將所有cron作業(yè)都設(shè)置在午夜或其他任何整點(diǎn)時(shí)間執(zhí)行

3.5.2.2.混合的方式設(shè)置時(shí)間，分散負(fù)載

4.系統(tǒng)容量

4.1.無論系統(tǒng)資源是需要數(shù)月、數(shù)周還是數(shù)秒才能完成整備，最終都可能導(dǎo)致不同層級(jí)之間的處理速率不匹配

4.2.由于容量不對(duì)等，前端總是有能力來壓倒后端

4.3.將系統(tǒng)容量均勻地進(jìn)行匹配，是不切實(shí)際的

4.3.1.除了某一天會(huì)派上用場(chǎng)，其他時(shí)間99%的基礎(chǔ)設(shè)施將處于閑置狀態(tài)

4.4.對(duì)于服務(wù)的構(gòu)建，如果不能使之全部滿足前端潛在的壓倒性需求，那么就必須構(gòu)建服務(wù)調(diào)用方和服務(wù)提供方的韌性，從而能夠應(yīng)對(duì)海嘯般襲來的請(qǐng)求

4.5.對(duì)服務(wù)調(diào)用方來說，當(dāng)響應(yīng)獲取速度變慢或連接被拒絕時(shí)，使用斷路器模式有助于緩解下游服務(wù)的壓力

4.6.對(duì)服務(wù)提供方來說，可以使用握手和背壓通知調(diào)用方，限制調(diào)用方發(fā)送請(qǐng)求的速度

4.7.使用艙壁模式，為關(guān)鍵服務(wù)的高優(yōu)先級(jí)調(diào)用方預(yù)留系統(tǒng)容量

5.系統(tǒng)容量失衡

5.1.放大效應(yīng)的特例

5.2.在QA環(huán)境中很少能觀察到的問題

5.2.1.主要原因是每個(gè)系統(tǒng)的QA環(huán)境通常會(huì)縮小到只有兩臺(tái)服務(wù)器

5.2.2.檢查服務(wù)器和線程的數(shù)量

5.2.3.實(shí)現(xiàn)QA環(huán)境虛擬化并實(shí)現(xiàn)擴(kuò)展

5.2.4.重視接口的兩側(cè)

5.3.考驗(yàn)機(jī)能幫助驗(yàn)證前端系統(tǒng)能否良好地實(shí)現(xiàn)降級(jí)

5.4.關(guān)系中一方的增幅變化大大超過另一方

5.5.宣傳帶來的流量高峰，就更難以預(yù)測(cè)了

5.5.1.自黑式

5.5.2.季節(jié)性、市場(chǎng)驅(qū)動(dòng)或宣傳驅(qū)動(dòng)等流量模式的變化，會(huì)導(dǎo)致前端系統(tǒng)的大量請(qǐng)求涌向后端系統(tǒng)（通常是良性的），就像熱門的社交媒體帖子導(dǎo)致網(wǎng)站流量劇增

5.6.要為出現(xiàn)任何狀況做好準(zhǔn)備

5.6.1.可以使用系統(tǒng)容量建模的方法，確保系統(tǒng)能力至少在可變范圍之內(nèi)

5.6.2.如果系統(tǒng)具有韌性，那么它可能會(huì)減慢處理速度，甚至當(dāng)無法在允許的時(shí)間內(nèi)處理事務(wù)時(shí)，就開始出現(xiàn)“快速失敗”

5.6.2.1.當(dāng)負(fù)載壓力減弱后，系統(tǒng)應(yīng)該還能夠恢復(fù)回來

5.6.3.使用自動(dòng)擴(kuò)展應(yīng)對(duì)激增的訪問請(qǐng)求

5.6.3.1.存在時(shí)間相對(duì)滯后的問題，并且還會(huì)將問題向下轉(zhuǎn)移到超載的平臺(tái)服務(wù)上

關(guān)鍵詞：