# REL05-BP03 控制和限制重試呼叫
使用指數退避以在逐漸延長間隔後重試。引進抖動來隨機化這些重試間隔，並限制重試次數上限。
分散式軟體系統中的典型元件包括伺服器、負載平衡器、資料庫和 DNS 伺服器。在操作中，且操作可能失敗時，任何這些項目都可能開始產生錯誤。處理錯誤的預設技術是在用戶端實作重試。此技術可提高應用程式的可靠性和可用性。不過，如果用戶端在發生錯誤時立即嘗試重試失敗的操作，則網路很快就會因為新的和重試的請求而大規模地變得飽和，且每個請求都會爭奪網路頻寬。這可能會導致 *重試暴風，* 而該情況會降低服務的可用性。此模式可能會持續進行，直到整個系統出現故障為止。
若要避免這類情境，應該使用一般指數退避等 *退避演算法* 。指數退避演算法會逐漸降低執行重試的速率，從而避免網路擁塞。
許多開發套件和軟體程式庫 (包括來自 AWS 的程式庫) 都會實作這些演算法的一個版本。不過， **絕對不要假設退避演算法存在，請一律測試並驗證是否如此。**
單靠簡單退避是不夠的，因為在分散式系統中，所有用戶端都可能會同時退避，從而建立重試呼叫的叢集。Marc Brooker 在其部落格文章 [指數退避和抖動](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)，說明了如何修改指數退避中的 wait () 函數，以防止重試呼叫的叢集。解決 *方法* 是在 wait() 函數中新增抖動。為避免重試太久，實作時應該將退避上限設為最大值。
最後，請務必設定 *最大重試次數* 或經過時間，之後重試就會失敗。AWS 開發套件預設情況下可實作此功能，並可以對其進行設定。對於堆疊中較低的服務，最大重試限制為零或一時可限制風險，但仍然有效，因為重試會委派給堆疊中較高的服務。
**若未建立此最佳實務，暴露的風險等級：** 高
## 實作指引
+ 控制和限制重試呼叫。使用指數退避以在逐漸延長間隔後重試。引進抖動來隨機化這些重試間隔，並限制重試次數上限。
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Amazon SDK 預設會實作重試和指數退避。呼叫自己的相依服務時，在相依性層中實作類似的邏輯。根據您的使用案例確定逾時時間以及何時停止重試。
## 資源
**相關文件：**
+ [Amazon API Gateway：調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS 中的錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library：快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**相關影片：**
+ [重試、退避和抖動：AWS re:Invent 2019：Amazon Builders' Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)