讀發(fā)布帅刀！設(shè)計與部署穩(wěn)定的分布式系統(tǒng)（第2版）筆記09_一窩蜂和容量.png

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

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

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

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

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

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

2.2. 系統(tǒng)達到穩(wěn)態(tài)時的負載伐庭，會與系統(tǒng)啟動或周期性運行的負載存在明顯不同

2.3. 示例

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

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

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

2.3.4. 大多數(shù)HTTP請求會轉(zhuǎn)換為一個或多個數(shù)據(jù)庫查詢

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

3. 一窩蜂

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

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

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

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

3.4.1. 在代碼升級和重新運行之后去件，啟動多臺服務(wù)器

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

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

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

3.4.5. 阻塞許多線程的所有地方，它們在等待某個線程完成工作

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

3.4.6. 虛擬用戶的腳本存在固定等待時間尤溜，則在進行負載測試時，就會產(chǎn)生流量脈沖

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

3.5. 解決方案

3.5.1. 使用增加的退避時間避免脈沖

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

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

3.5.2. 使用隨機時鐘擺動以分散需求

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

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

4. 系統(tǒng)容量

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

4.2. 由于容量不對等际插，前端總是有能力來壓倒后端

4.3. 將系統(tǒng)容量均勻地進行匹配碘耳，是不切實際的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.5.1. 自黑式

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

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

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

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

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

5.6.3. 使用自動擴展應(yīng)對激增的訪問請求

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