本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
REL05-BP04 快速失敗並限制佇列
在服務無法成功回應請求時快速檢錯。如此將可釋出與請求關聯的資源，並且使服務可在資源用盡時復原。快速檢錯是一種完善的軟體設計模式，可用來在雲端中建置高度可靠的工作負載。佇列也是一種完善的企業整合模式，可以平滑負載，並且讓用戶端在可容忍非同步處理時釋出資源。如果服務在正常情況下能夠成功回應，但在請求速率太高時會失敗，請使用佇列來緩衝請求。不過，請勿允許建置長佇列積存，這可能導致用戶端已放棄的過時請求受到處理。
預期成果：當系統遇到資源爭用、逾時、例外狀況或灰色失敗而使服務水準目標無法達成時，快速檢錯的策略可加快系統復原速度。必須吸納流量尖峰且能支應非同步處理的系統，可讓用戶端使用佇列緩衝處理後端服務的請求以快速釋出請求，藉此提升可靠性。緩衝處理要排入佇列的請求時，會實作佇列管理策略，以避免發生無法克服的積存。
常見的反模式：
-
實作訊息佇列，但不在DLQ磁碟區上設定無效字母佇列 （DLQ） 或警示，以偵測系統何時故障。
-
未測量訊息在佇列中的存留期，這是一種延遲測量，用以了解佇列取用者何時進度落後或發生錯誤導致重試。
-
當處理這些訊息沒有任何價值，且業務需求已不存在時，未清除佇列中已積存的訊息。
-
當最後的先出 （FIFO） 佇列更能滿足用戶端需求時，設定先出 （LIFO） 佇列，例如，當不需要嚴格排序，且待辦項目處理正在延遲所有新的和時間敏感請求，導致所有用戶端發生違反的服務層級時。
-
將內部佇列暴露至用戶端APIs，而不是將管理工作接收並將請求放置在內部佇列中的暴露。
-
藉由將資源需求分攤到不同請求型態，將過多的工作請求類型合併到可能加劇積存條件的單一佇列中。
-
儘管需要不同的監控、逾時和資源分配，仍在同一佇列中處理複雜而簡單的請求。
-
不驗證輸入或使用判斷提示在軟體中實作快速檢錯的機制，以對可用正常程序處理錯誤的較高層級元件快顯例外狀況。
-
不會從請求路由中移除錯誤的資源，特別是在失敗處於灰色地帶，因損毀和重新啟動、間歇性相依性失敗、容量減少或網路封包遺失而導致成功與失敗並存。
建立此最佳實務的優勢：快速檢錯的系統更容易偵錯和修正，並且在發布至生產環境之前，常會出現編碼和組態方面的問題。納入有效佇列策略的系統，可針對流量尖峰和間歇性系統失敗狀況提供更高的恢復能力和可靠性。
未建立此最佳實務時的曝險等級：高
實作指引
快速檢錯的策略可以編碼為軟體解決方案，並設定到基礎設施中。除了快速檢錯以外，佇列也是一種簡單而強大的架構技術，可將系統元件平滑負載分離。Amazon CloudWatch
實作步驟
-
在軟體中實作程式化判斷提示或特定指標，並使用這些提示或指標來明確提醒系統問題。Amazon CloudWatch 可協助您根據應用程式日誌模式和SDK儀器建立指標和警示。
-
使用 CloudWatch 指標和警示來避免增加處理延遲或重複處理請求的受損資源。
-
使用非同步處理，方法是設計APIs接受請求，並使用 Amazon 將請求附加到內部佇列，SQS然後使用成功訊息回應訊息產生用戶端，以便用戶端可以在後端佇列取用者處理請求時釋出資源並繼續進行其他工作。
-
測量和監控佇列處理延遲，方法是在每次從佇列中除去訊息時產生 CloudWatch 指標，方法是立即與訊息時間戳記進行比較。
-
因失敗而無法成功處理訊息，或無法在服務水準協議內處理磁碟區中的流量尖峰時，請將較舊或過多的流量排除至溢滿佇列。這可讓您優先處理新工作，並且等到有可用的容量時再處理較舊的工作。此技術是LIFO處理方法的近似值，並允許所有新工作的正常系統處理。
-
使用無效字母或重新驅動佇列，將無法處理的訊息從積存移到可稍後再研究和解析的位置
-
進行重試，或在可接受的情況下，藉由比較目前時間與訊息時間戳記，捨棄與請求用戶端不再相關的訊息，將舊訊息捨棄。
資源
相關的最佳實務：
相關文件：
相關範例：
相關影片：
相關工具：
