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. 存在時間相對滯後的問題，並且還會將問題向下轉移到超載的平臺服務上