為什麼網路請求總是充滿不確定性
在分散式系統架構中，客戶端與伺服器之間的通訊永遠無法保證絕對的穩定。當使用者點擊「付款」按鈕時，如果網路發生微小的延遲或中斷，客戶端往往無法確認請求是否已被伺服器成功接收並處理。這時，自動重試機制（Retry）成為了開發者的首選防禦策略，但它卻同時埋下了「重複執行」的巨大隱憂。
若一個支付請求在伺服器端已經處理完成，但回傳確認訊息的過程中網路斷線，客戶端因為收不到回應而發起第二次請求，系統若缺乏防禦機制，極易導致重複扣款或資料不一致。這種「即使請求執行多次，系統最終狀態依然與執行一次相同」的特性，在軟體工程中被稱為「冪等性（Idempotency）」。
冪等性的底層運作機制
冪等性的核心在於伺服器如何識別「同一個請求」。在 HTTP 協議中，GET、PUT 與 DELETE 方法理論上具備天然的冪等性，因為無論查詢多少次，資源狀態都不應改變；然而，POST 請求則不具備此特性。為了在 POST 請求中實現冪等，我們必須引入「冪等識別碼（Idempotency Key）」。
識別碼的生成邏輯
識別碼通常由客戶端在發起請求時生成，這是一個唯一的 UUID 或業務序號。伺服器接收到請求後，會先檢測該識別碼是否已存在於緩存（如 Redis）中。若已存在，則直接回傳之前儲存的處理結果，而不再進行第二次業務邏輯運算。這種機制將「執行」與「查詢」分離，確保了交易的安全性。
常見 HTTP 方法的冪等性差異判斷
並非所有 API 都需要嚴格的冪等性設計，開發者應根據業務場景進行評估。以下表格列出了不同 HTTP 方法在冪等性上的表現與適用情境：
| 方法 | 冪等性 | 適用情境 |
|---|---|---|
| GET | 是 | 資料查詢、獲取資源 |
| PUT | 是 | 資源完全更新或覆蓋 |
| DELETE | 是 | 刪除特定資源 |
| POST | 否 | 建立新資源、支付交易 |
| PATCH | 否 | 資源的部分更新 |
實作策略：從請求攔截到狀態緩存
在正式進入程式開發前，建議建立一套標準的攔截器流程。首先，API Gateway 或 Middleware 層必須能夠解析請求標頭中的 Idempotency-Key 欄位。如果該欄位缺失，對於非冪等方法，系統應採取拒絕受理並返回 400 Bad Request 的策略，以防止意外的重複操作。
實作步驟檢查清單
- 定義 Idempotency-Key 請求標頭格式。
- 在伺服器端建立針對 Key 的鎖定機制（Distributed Lock）。
- 檢查 Redis 是否存在該 Key 的處理狀態。
- 若狀態為「處理中」，拒絕新請求或等待鎖定釋放。
- 若狀態為「已完成」，直接回傳快取結果。
- 若無紀錄，執行業務邏輯，並儲存執行結果與狀態。
處理常見的開發誤區
許多開發者誤以為「只要檢查資料庫是否重複」就是冪等性，這其實是極大的誤區。資料庫查詢往往伴隨高昂的 I/O 成本，在併發量高的場景下，依賴資料庫作為冪等判斷的唯一依據，會導致嚴重的效能瓶頸。正確的做法是使用高效的記憶體資料庫（如 Redis）作為第一道防線。
另一個常見錯誤是將「冪等性」與「事務（Transaction）」混為一談。事務確保了操作的原子性，而冪等性則確保了操作的重複安全性。兩者在分散式系統中應該是互補的關係，而非相互取代。若只做事務處理而忽略冪等，系統在處理網路抖動時仍會暴露於重複交易的風險之下。
例外情境與狀態一致性維護
在某些極端情況下，例如伺服器在執行業務邏輯過程中崩潰，導致狀態紀錄尚未寫入 Redis，這時該如何處理？這涉及到了「重試策略」的設計。我們建議採用「先佔位、後更新」的策略：在執行業務前，先將 Key 寫入並標記為 `PENDING`。即使後續崩潰，客戶端再次重試時，伺服器能識別到該任務正在處理中，從而避免資源衝突。
下一步的系統彈性思考
當 API 具備了完善的冪等性，系統的韌性將大幅提升。開發者應開始關注「冪等失敗」的錯誤處理：例如當伺服器回傳 409 Conflict 告知該 Key 正在處理中時，客戶端應如何實作指數退避（Exponential Backoff）演算法，以避免在系統負載過高時發起過多的重試請求。這不僅是技術實作的細節，更是建構現代化穩定 API 的核心素養。