讀完軟體測試之後，接下來讀到一個比較有幫助的章節是如何處理系統超載，書中提供了一些可供參考的策略。撇除那些針對大型分散式系統的部分，我想整理一下對於我們這種小型的服務也具有參考價值的做法。

為每個使用者設定限額

這個部分主要是討論如何因應全域超載 (global overloading)，當它發生的時候，我們也應該要避免所以人都沒有辦法正常使用服務，所以針對每個使用者去限制它可以使用的資源額度便是一種有效的策略。

以 NOJ 來說，之前比較常發生在考試時產生的大量 submission 塞住了整台 server，導致所有人進行的任何操作都變得非常緩慢，在這種情況下，我想可以就兩個層面去進行限制：

• 容器：第一個部分是應該要針對容器去進行資源的限制，避免服務中的特定元件消耗掉了太多資源，進而導致其他元件無法正常運作。
• 使用者：上述問題發生的其中一個成因是因為後端接受了太多 submission 的請求，所以針對 submission 數量去做控管是個方法。然而若是基於請求的先後順序去接受 submission 請求可能會阻塞其他人的請求，因此我想若是可以限制每位使用者在單位時間內可以發送的 submission 數量或許會更好。

客戶端節流

有些時候，大量地從 server 端拒絕請求也會造成額外的負擔，若是可以預期接下來的請求也會被拒絕的話，其實在客戶端就拒絕發送可以減小後端受到的壓力。

書中是採用請求數量與被接受請求數量的比例去決定發送請求的成功機率，當被拒絕太多次則會逐漸提高拒絕發送請求的機率。

重要性

將請求按照重要程度分級，可以讓後端決定是否要處理這項請求，以書中來說它分成了四個等級：

• CRITICAL_PLUS
• CRITICAL
• SHEDDABLE_PLUS
• SHEDDABLE

當然也只是個參考，可以依照需求增減。

小結

如何優雅的處理超載的情況是個重要的議題，並不是說通通拒絕掉就好，而是應該考量如何盡可能降低對使用者的影響。話說要能夠處理這些情況，我想好好記錄服務當前的狀態是個重要的前提。希望今天記錄下來的這些技巧對於這學期重構系統會有些幫助...

BTW，之前紀錄的有關機敏資料管理的修正已經發出 PR 了，果然有寫文章有差，不然去年一直在逃避處理這些問題。