1. 停電事故后電力恢復的方式
1.1. 停電后常見的情形是，送電幾秒鐘后又再次斷電
1.2. 數百萬臺空調和冰箱的用電需求，使剛付訓復的電力供應發生過載
1.3. 當電力供應不足時，增加的電流很快就到達滿負荷，導致過載，觸發斷路器跳閘，燈再次熄滅
2. 經驗教訓
2.1. 系統規模相對較小的組件子集上永遠不會出現這種情況
2.2. 系統達到穩態時的負載，會與系統啟動或周期性運行的負載存在明顯不同
2.3. 示例
2.3.1. 一個應用程式服務器農場的啟動程序
2.3.2. 每臺服務器都需要連接到資料庫，并加載一定數量的參考資料或種子資料
2.3.3. 每臺服務器的快取都從空閑狀態開始，逐漸形成一個有用的作業集
2.3.4. 大多數HTTP請求會轉換為一個或多個資料庫查詢
2.3.5. 當應用程式啟動時，資料庫上的瞬時負載要比運行一段時間后的負載高得多
3. 一窩蜂
3.1. 一堆服務器一同對資料庫施加瞬時負載
3.2. 是對系統的集中使用，相比將峰值流量分散開后所需的系統能力，一窩蜂需要一個更高的系統容量峰值
3.3. 一窩蜂所需系統成本過高，高峰需求無法處理
3.4. 引發一窩蜂現象的情況
3.4.1. 在代碼升級和重新運行之后，啟動多臺服務器
3.4.2. 午夜（或任何一個整點時間）觸發cron作業
3.4.3. 配置管理系統推出變更
3.4.4. 當一些外部現象引起流量的同步“脈沖”時
3.4.5. 阻塞許多執行緒的所有地方，它們在等待某個執行緒完成作業
3.4.5.1. 這個狀態打破時，新釋放的執行緒就會對任何接收資料包的下游系統施加一窩蜂
3.4.6. 虛擬用戶的腳本存在固定等待時間，則在進行負載測驗時，就會產生流量脈沖
3.4.6.1. 腳本中的每個等待時間都應該附帶一個小的隨機時間增量
3.5. 解決方案
3.5.1. 使用增加的退避時間避免脈沖
3.5.1.1. 固定的重試時間間隔，會集中那段時間的呼叫方需求
3.5.1.2. 使用退避演算法，不同呼叫方在經過自己的退避時間后，在不同的時間點發起呼叫
3.5.2. 使用隨機時鐘擺動以分散需求
3.5.2.1. 不要將所有cron作業都設定在午夜或其他任何整點時間執行
3.5.2.2. 混合的方式設定時間，分散負載
4. 系統容量
4.1. 無論系統資源是需要數月、數周還是數秒才能完成整備，最終都可能導致不同層級之間的處理速率不匹配
4.2. 由于容量不對等，前端總是有能力來壓倒后端
4.3. 將系統容量均勻地進行匹配，是不切實際的
4.3.1. 除了某一天會派上用場，其他時間99%的基礎設施將處于閑置狀態
4.4. 對于服務的構建，如果不能使之全部滿足前端潛在的壓倒性需求，那么就必須構建服務呼叫方和服務提供方的韌性，從而能夠應對海嘯般襲來的請求
4.5. 對服務呼叫方來說，當回應獲取速度變慢或連接被拒絕時，使用斷路器模式有助于緩解下游服務的壓力
4.6. 對服務提供方來說，可以使用握手和背壓通知呼叫方，限制呼叫方發送請求的速度
4.7. 使用艙壁模式，為關鍵服務的高優先級呼叫方預留系統容量
5. 系統容量失衡
5.1. 放大效應的特例
5.2. 在QA環境中很少能觀察到的問題
5.2.1. 主要原因是每個系統的QA環境通常會縮小到只有兩臺服務器
5.2.2. 檢查服務器和執行緒的數量
5.2.3. 實作QA環境虛擬化并實作擴展
5.2.4. 重視介面的兩側
5.3. 考驗機能幫助驗證前端系統能否良好地實作降級
5.4. 關系中一方的增幅變化大大超過另一方
5.5. 宣傳帶來的流量高峰，就更難以預測了
5.5.1. 自黑式
5.5.2. 季節性、市場驅動或宣傳驅動等流量模式的變化，會導致前端系統的大量請求涌向后端系統（通常是良性的），就像熱門的社交媒體帖子導致網站流量劇增
5.6. 要為出現任何狀況做好準備
5.6.1. 可以使用系統容量建模的方法，確保系統能力至少在可變范圍之內
5.6.2. 如果系統具有韌性，那么它可能會減慢處理速度，甚至當無法在允許的時間內處理事務時，就開始出現“快速失敗”
5.6.2.1. 當負載壓力減弱后，系統應該還能夠恢復回來
5.6.3. 使用自動擴展應對激增的訪問請求
5.6.3.1. 存在時間相對滯后的問題，并且還會將問題向下轉移到超載的平臺服務上
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/555819.html
標籤：其他
上一篇：讀發布！設計與部署穩定的分布式系統（第2版）筆記09_一窩蜂和容量
下一篇：返回列表