本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 例外狀況處理和重試
<a name="transactions-exceptions"></a>

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

## 為什麼重試邏輯很重要
<a name="why-retry-logic-matters"></a>

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

## 不區分重試的風險
<a name="risks-of-indiscriminate-retries"></a>

根據預設，重試每個錯誤可能會導致多種意外後果：
+ **增加爭用** – 當重複重試因高並行而失敗的操作時，整體爭用可能會惡化。這可能會導致交易失敗和效能降低的週期。
+ **資源耗盡** – 不區分重試可能會耗用用戶端和伺服器端的其他系統資源。這可能會導致限流或甚至服務降級。
+ **用戶端的延遲增加** – 過度重試可能會導致用戶端應用程式的嚴重延遲，特別是每次重試都涉及等待期間時。這可能會對使用者體驗和下游程序產生負面影響。

## 制定實際的重試策略
<a name="developing-practical-retry-strategy"></a>

若要建置彈性且有效率的應用程式，請針對應用程式可能遇到的特定錯誤條件，開發量身打造的重試策略。以下是引導您方法的一些考量：
+ **識別可重試的錯誤** – 並非所有例外狀況都應該重試。例如，語法錯誤、身分驗證失敗或無效的查詢不應觸發重試。Neptune 提供[錯誤代碼](https://docs.aws.amazon.com//neptune/latest/userguide/errors-engine-codes.html)和一般建議，這些錯誤可以安全地重試，但您需要實作適合您使用案例的邏輯。
+ **實作指數退避** – 對於暫時性錯誤，請使用指數退避策略逐步增加重試之間的等待時間。這有助於緩解爭用，並降低串聯失敗的風險。
+ **考慮初始暫停長度** – 如果伺服器沒有獲得足夠的時間來釋放查詢成功所需的資源，則執行第一次重試速度可能會太快結束，並出現相同的錯誤。在適當情況下長時間暫停可以減少浪費的請求和伺服器壓力。
+ **新增抖動至退避** – 雖然指數退避有效，但如果許多用戶端同時失敗，然後一起重試，仍可能導致同步重試風暴。將抖動新增為退避延遲的小隨機變化，有助於分散重試嘗試，從而降低所有用戶端同時重試並導致負載再次激增的機會。
+ **限制重試嘗試**次數 – 設定合理的重試次數上限，以防止無限迴圈和資源耗盡。
+ **監控和調整** – 持續監控應用程式的錯誤率，並視需要調整重試策略。如果您注意到特定操作的重試次數很高，請考慮操作是否可以最佳化或序列化。

如需以指數退避和抖動做為一般雲端設計模式的深入討論，請參閱 AWS 方案指引中的[以退避重試](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)。

## 範例方案
<a name="example-scenarios"></a>

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


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

### 案例 1：短查詢的偶爾 CME
<a name="scenario-1-occasional-cme"></a>

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

### 案例 2：長時間執行的查詢經常使用 CME
<a name="scenario-2-frequent-cme"></a>

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

### 案例 3：昂貴查詢的記憶體限制
<a name="scenario-3-memory-limits"></a>

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

### 案例 4：中度查詢逾時
<a name="scenario-4-timeout-moderate"></a>

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

## 監控與可觀測性
<a name="monitoring-and-observability"></a>

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

### MainRequestQueuePendingRequests
<a name="main-request-queue"></a>

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

### 其他 CloudWatch 指標
<a name="other-cloudwatch-metrics"></a>

`CPUUtilization`、 `TotalRequestsPerSecond`和 查詢延遲等其他 [Neptune 指標](https://docs.aws.amazon.com/neptune/latest/userguide/cw-metrics.html)提供額外的內容。例如，高 CPU 和 I/O 結合增加的佇列長度，可能表示您的叢集超載，或查詢太大或太頻繁。可以在這些指標上設定 [CloudWatch 警示](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)，以提醒您異常行為，並協助您將錯誤或重試的峰值與基礎資源限制相關聯。

### Neptune 狀態和查詢 APIs
<a name="neptune-status-query-apis"></a>

[Gremlin 的 Neptune 狀態 API](https://docs.aws.amazon.com//neptune/latest/userguide/gremlin-api-status.html) 及其 [OpenCypher](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-opencypher-status.html) 和 [SPARQL](https://docs.aws.amazon.com//neptune/latest/userguide/sparql-api-status.html) 的類似 APIs 提供叢集上接受和執行的查詢的即時檢視，這有助於診斷瓶頸或即時了解重試邏輯的影響。

透過結合這些監控工具，您可以：
+ 偵測重試何時導致佇列和效能降低。
+ 識別何時擴展 Neptune 叢集或最佳化查詢。
+ 驗證您的重試策略是否正在解決暫時性故障，而不會遮罩更深的問題。
+ 接收有關新興爭用或資源耗盡的早期警告。

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