例外狀況處理和重試

在 Neptune 上建置強大的應用程式通常意味著為意外做好準備，特別是在處理資料庫傳回的錯誤時。伺服器端例外狀況最常見的回應之一是重試失敗的操作。雖然重試邏輯對於彈性系統至關重要，但您需要了解並非所有錯誤都應該以相同的方式處理。與其依賴一般重試行為，深思熟慮的方法可協助您建置更可靠且更有效率的應用程式。

為什麼重試邏輯很重要

重試邏輯是任何分散式應用程式的關鍵元件。暫時性問題，例如網路不穩定、暫時性資源限制或並行修改衝突，都可能導致操作失敗。在許多情況下，這些失敗並不表示永久問題，可以透過等待並重試來解決。實作穩固的重試策略可確認分散式系統中環境不完美的實際情況，確保更強大的可靠性和持續性，並減少手動介入的需求。

不區分重試的風險

根據預設，重試每個錯誤可能會導致多種意外後果：

• 增加爭用 – 當重複重試因高並行而失敗的操作時，整體爭用可能會惡化。這可能會導致交易失敗和效能降低的週期。

• 資源耗盡 – 不區分重試可能會耗用用戶端和伺服器端的其他系統資源。這可能會導致限流或甚至服務降級。

• 用戶端的延遲增加 – 過度重試可能會導致用戶端應用程式的嚴重延遲，特別是每次重試都涉及等待期間時。這可能會對使用者體驗和下游程序產生負面影響。

制定實際的重試策略

若要建置彈性且有效率的應用程式，請針對應用程式可能遇到的特定錯誤條件，開發量身打造的重試策略。以下是引導您方法的一些考量：

• 識別可重試的錯誤 – 並非所有例外狀況都應該重試。例如，語法錯誤、身分驗證失敗或無效的查詢不應觸發重試。Neptune 提供錯誤代碼和一般建議，這些錯誤可以安全地重試，但您需要實作適合您使用案例的邏輯。

• 實作指數退避 – 對於暫時性錯誤，請使用指數退避策略逐步增加重試之間的等待時間。這有助於緩解爭用，並降低串聯失敗的風險。

• 考慮初始暫停長度 – 如果伺服器沒有獲得足夠的時間來釋放查詢成功所需的資源，則執行第一次重試的速度可能會太快，並出現相同的錯誤。在適當情況下長時間暫停可以減少浪費的請求和伺服器壓力。

• 新增抖動至退避 – 雖然指數退避有效，但如果許多用戶端同時失敗，然後一起重試，仍可能導致同步重試風暴。將抖動新增為退避延遲的小隨機變化，有助於分散重試嘗試，從而降低所有用戶端同時重試並導致負載再次激增的機會。

• 限制重試嘗試次數 – 設定合理的重試次數上限，以防止無限迴圈和資源耗盡。

• 監控和調整 – 持續監控應用程式的錯誤率，並視需要調整重試策略。如果您注意到特定操作的重試次數很高，請考慮操作是否可以最佳化或序列化。

範例方案

正確的重試策略取決於失敗的性質、工作負載和您觀察到的錯誤模式。下表摘要說明一些常見的失敗案例，以及如何將重試策略考量套用至每個案例。針對其他內容，說明段落如下。

案例	可重試？	退避與抖動	初始暫停	重試限制	監控和調整
短期查詢上的偶爾 CME	是	短退避，新增抖動	短 （例如 100 毫秒）	高	留意提高的 CME 費率
長時間執行查詢的頻繁 CME	是	較長的退避，新增抖動	較長 （例如 2 秒）	適中	調查並減少爭用
昂貴查詢的記憶體限制	是	長退避	長 （例如 5-10 秒）	低	最佳化查詢，如果持續，則提醒
中等查詢逾時	也許可以	中等退避，新增抖動	中等 （例如 1 秒）	低至中度	評估伺服器負載和查詢設計

案例 1：短查詢的偶爾 CME

對於在簡短、簡單的更新期間不常ConcurrentModificationException出現的工作負載，這些錯誤通常是暫時性且安全的重試。在第一次重試之前，使用短暫的初始暫停 （例如 100 毫秒）。這次允許清除任何短暫鎖定。結合此值與短指數退避和抖動，以避免同步重試。由於重試成本較低，因此較高的重試限制是合理的。不過，請監控 CME 速率，以捕捉資料中爭用增加的任何趨勢。

案例 2：長時間執行的查詢經常使用 CME

如果您的應用程式在長時間執行的查詢上經常看到 CMEs，則表示爭用更為嚴重。在此情況下，請從較長的初始暫停 （例如 2 秒） 開始，讓保留鎖定的目前查詢有足夠時間完成。使用較長的指數退避並新增抖動。限制重試次數，以避免過度延遲和資源使用。如果爭用持續存在，請檢閱工作負載是否有模式，並考慮序列化更新或減少並行以解決根本原因。

案例 3：昂貴查詢的記憶體限制

當已知資源密集型查詢期間發生記憶體型錯誤時，只有在長時間的初始暫停 （例如 5 到 10 秒或更多） 後，才能重試，以允許伺服器釋出資源。使用長退避策略並設定低重試限制，因為重複失敗不太可能在沒有變更查詢或工作負載的情況下解決。持續性錯誤應觸發警示，並提示檢閱查詢複雜性和資源用量。

案例 4：中度查詢逾時

中等成本查詢的逾時是更模棱兩可的情況。有時，如果逾時是由於伺服器負載或網路條件的暫時峰值而導致的，則重試可能會成功。從中等初始暫停開始 （例如 1 秒），讓系統有機會復原。套用中度退避並新增抖動，以避免同步重試。將重試限制保持在低至中度，因為重複的逾時可能表示查詢或伺服器容量有更深的問題。監控模式：如果逾時頻繁，請評估查詢是否需要最佳化，或 Neptune 叢集是否佈建不足。

監控與可觀測性

監控是任何重試策略的關鍵部分。有效的可觀測性可協助您了解重試邏輯的運作狀態，並在工作負載或叢集組態中需要注意時提供早期訊號。

MainRequestQueuePendingRequests

此 CloudWatch 指標會追蹤 Neptune 輸入佇列中等待的請求數量。值上升表示查詢正在備份，這可能是過度爭用、資源佈建不足或重試風暴的跡象。監控此指標可協助您找出重試策略何時造成或複合佇列問題，並提示您在失敗升級之前調整方法。

其他 CloudWatch 指標

CPUUtilization、 TotalRequestsPerSecond和 查詢延遲等其他 Neptune 指標提供額外的內容。例如，高 CPU 和 I/O 結合增加的佇列長度，可能表示您的叢集超載，或查詢太大或太頻繁。可以在這些指標上設定 CloudWatch 警示，以提醒您異常行為，並協助您將錯誤或重試的峰值與基礎資源限制相互關聯。

Neptune 狀態和查詢 APIs

Gremlin 的 Neptune 狀態 API 及其 OpenCypher 和 SPARQL 的類似 APIs 提供叢集上接受和執行的查詢的即時檢視，這有助於診斷瓶頸或即時了解重試邏輯的影響。

透過結合這些監控工具，您可以：

• 偵測重試何時造成佇列和效能降低。

• 識別何時擴展 Neptune 叢集或最佳化查詢。

• 驗證您的重試策略是否正在解決暫時性故障，而不會遮罩更深的問題。

• 接收有關新興爭用或資源耗盡的早期警告。

主動監控和提醒對於維持良好的 Neptune 部署至關重要，尤其是在您應用程式的並行和複雜性增加時。