抵禦負載怪獸攻擊 確保可伸縮性的7條祕訣

　　之前我們討論過系統負載增加時將會遭遇的42個怪獸問題。開發者又該如何完成程式的設計，才能讓程式既易於擴充套件又具備高可靠性？這裡有幾條法則以應對負載怪獸的襲擊，當然這都是在程式低擴充套件等級編寫下需要注意的事項：

　　1. 限制資源使用的比例

　　這在實現擴充套件的應用程式中可能是最重要的規則，可以這麼認為：

• 將資源限制到你認為可以支撐應用程式的等級，比如：保證可以在記憶體中處理一定數量的物件。所以如果我們一直按比例新增資源，那麼就可以防止資源枯竭情況的出現。
• 針對個體資源試用不同的設計方式

　　一些例子：

• 我們需要儲存一個訂單列表，訂單中商品的金額大於20美元（隨便多少）。這種情況下記憶體中儲存的絕不能是這些商品，因為商品的數量可能遠大於訂單的數量。你可以對比列表中訂單的數量和資源的使用率，這樣你就清楚了你的系統可以支撐多少個訂單。
• 使用Merge Aggregation：同一個物件說的所有操作應該整合到一個請求中，而不是為每個操作分別做請求。比如，一個create和一個update就可以整合進一個請求。

　　2. Merge Aggregation

　　在Merge Aggregation中，獨立的資料和/或命令聚合到一處，用的是規則1的思想。

　　舉個例子，如果一個物件中包含了以下幾個命令序列：

• Create
• Update
• Update

　　這三個分開的請求，可以融合到一處。如果有個迴圈執行了這個請求100次，那麼我們的佇列中始終只有一個請求。

　　另一個例子是屬性修改事件，獨立的改變也可以融合到一處。想象一下這樣做的益處有多大，佇列的長度永遠都不會超過物件的數量，不管觸發了多少事件。完成這一點需要通訊子系統的配合，所以必須確保相對智慧。

　　3. Delete Aggregation

　　在Delete Aggregation中，資料和/或請求在允許的情況下將會被刪除。比如，做以下兩個操作：

• Create
• Delete

　　在這個聚合中，許多create和delete操作將會被刪除，大量的資源將被釋放。

　　4. Batch Aggregation

　　定時分析的批處理將會把大量的資料整合在一起，從而大幅度的提高效能。逐個的進行操作永遠比批量的處理來的慢。理念上應用程式不需要手動的做批處理業務，比如：框架會幫助你完成這個聚合。

　　5. Change Aggregation

　　在Change Aggregation中，所有的改變都將會被聚合到一處。當然這與Merge Aggregation不同，在Change Aggregation中我們注意到的是物件/資料改變的狀態，而不是它被改變了多少次；取代為每次改變做記錄，我們將把它的值傳送給一個客戶端，然後告訴它事情已經改變了。因為在大型系統中，我們不可能為事物的每次改變做記錄。

　　6. Integration Aggregation

　　在Integration Aggregation中，事件只有在它存在過一個週期被關閉後才會被建立。

　　最常見的例子。一個警報只有在聚合週期結束後才被設定。當硬體發生問題等其它情況，我們可以建立一個alarm storm。

　　7. 解除安裝

　　解除安裝同樣是個擴充套件方案，在這裡工作將會被拒絕直到有足夠的資源去執行它。

　　舉個例子，在一個呼叫處理系統（call processing system）中，呼叫的數量將會被限制。任何在限制之後的出現的呼叫都會被拒絕，這將會給現有的呼叫足夠的處理時間。

　　一些其它的解除安裝例子：

• 限制單節點FTP上的Session數量
• 在忙碌時將改伺服器上的請求轉發到另一個伺服器
• 公共電話系統在提示所有的呼叫正忙去阻止新呼叫的接入

　　寫在最後

　　當然一篇文章不可能包括負載加重後出現的所有問題，也不可能包括所有的應對方案。但是可以肯定是對自己系統做足夠的認知，基於充足的資訊做好設計決策，才能減少系統在擴充套件後所帶來的問題。

　　英文來源：7 Life Saving Scalability Defenses Against Load Monster Attacks