分布式系統中的故障不可避免：網絡分區、超時和間歇性連接問題都可能導致故障。當這些故障發生時，可能會導致延遲、事務不完整或數據狀態不一致，最終影響用戶體驗和系統可靠性。當系統出現故障時，客戶端通常會重試請求，以確保操作能夠成功完成。
然而，如果沒有適當的處理機制，重試可能會導致意外后果，例如重復事務、數據損壞或狀態不一致。在系統或API中實現冪等性，可以確保在這些故障之后的重試能夠可靠地處理，從而維護系統的完整性和一致性。
什么是冪等性？
冪等性是一種操作特性，它保證無論執行多少次，結果都相同。換句話說，多次執行該操作不會改變首次成功執行后的結果。
舉個例子：假設客戶端通過調用服務來更新一筆交易，服務會更新其數據庫以將交易標記為已完成。然而，在服務向客戶端返回成功響應時，發生了臨時的網絡故障，導致客戶端無法收到成功消息。因此，客戶端不知道請求是否已成功處理，于是再次重試請求。
如果沒有冪等性，第二次請求可能會再次更新交易，從而導致意外的副作用。而當實現了冪等性時，系統會識別第二次調用為重復請求，并確保數據庫保持不變，防止重復更新。
何時需要系統具備冪等性？
是否需要冪等性取決于具體的應用場景，主要適用于寫操作。
讀操作無需進行冪等性檢查，因為它們本身就具有冪等性。由于讀操作不會改變系統狀態，只要底層數據保持不變，多次執行讀操作的結果將始終相同。
并非所有寫操作都需要冪等性。判斷是否需要冪等性的一個關鍵原則是，評估操作是否基于輸入進行計算并改變系統狀態。
例如，一個簡單地將輸入直接存儲到數據庫中的寫操作無需冪等性，因為使用相同的輸入重復調用只會覆蓋數據，而不會導致不一致（例如，將一個數字設置為X）。然而，一個修改現有狀態的寫操作（例如，將一個數字增加X）則需要冪等性，以確保一致性。
實現冪等性的機制
在分布式系統中，實現冪等性有多種方法。以下是一些常用的技術：
1. 唯一鍵
實現冪等性的最常見方法是為每個請求分配唯一標識符。這種方法可以確保檢測并適當處理重復請求。
請求處理的一般流程：
- 從請求中提取唯一標識符。
- 檢查是否已經處理過具有相同標識符的請求。
- 如果沒有（首次請求）：處理請求，將結果連同唯一標識符一起持久化，并返回結果。
- 如果有（重復請求）：檢索之前存儲的結果并返回，可選擇性地表明請求已被處理。
如果請求中未提供唯一標識符，系統可以通過計算所有輸入參數的哈希值并將其用作標識符來生成一個。但API文檔必須明確說明這一方法，以確保客戶端不在請求中包含可變字段，例如當前時間戳。否則，重試時可能會生成不同的標識符，從而失去冪等性的意義。
2. 樂觀鎖
樂觀鎖是一種在數據庫和分布式系統中用于處理對同一數據的并發更新的并發控制機制，同時盡量減少沖突。它也可以用來實現冪等性，采用“先讀后寫”的方式。
請求處理的一般流程：
- 客戶端從服務器讀取一個值及其版本號，假設為x。
- 客戶端發送更新請求，包含之前讀取的版本號（x）。
- 服務器檢查客戶端請求中的版本號是否與數據庫中的當前版本匹配。
- 如果匹配：服務器處理請求，并將版本號遞增（x → x+1）。
- 如果不匹配：請求被拒絕。版本號不匹配意味著數據已被更新，可能是由于重復請求或其他系統對數據的修改。
- 如果請求被拒絕，客戶端必須獲取最新的值及其更新后的版本號，并根據新的版本和值決定是否重試。
這種方法確保重復或過時的請求不會覆蓋最新數據，從而保持一致性并防止意外修改。
實現冪等性的挑戰
雖然冪等性至關重要，但其實現可能會引入復雜性，包括：
- 狀態管理：維護唯一鍵或版本號會增加系統的開銷，并需要高效的存儲和檢索機制。
- 處理副作用：某些操作會觸發副作用（例如發送郵件、觸發通知）。確保這些操作不會重復發生需要額外的保障措施。
- 分布式系統中的數據一致性：如果多個服務參與一個操作，那么在它們之間協調冪等性會變得更具挑戰性。
結論
理想的冪等性系統是不需要冪等性的系統——例如無狀態操作，其輸出始終直接由輸入決定。然而，在現實應用中，并非所有系統都能做到無狀態。例如，銀行系統在進行存款或取款等更新操作之前，必須先讀取當前賬戶余額。在這種情況下，實現冪等性對于維護一致的系統狀態、防止意外副作用以及通過避免重復交易或數據損壞來確保無縫的用戶體驗至關重要。
通過使用唯一鍵和樂觀鎖等技術，開發人員可以在權衡利弊的情況下確保冪等性。唯一鍵需要額外的存儲和請求跟蹤，樂觀鎖可能會在高并發環境中導致更高的拒絕率，而請求去重則依賴于維護日志，這可能會引入額外的開銷。
了解這些挑戰有助于為特定系統選擇合適的方法，使開發人員能夠構建能夠抵抗故障的系統，有效處理重試，并在分布式環境中維護數據完整性。
原文標題：Idempotency in Distributed Systems: When and Why It Matters，作者：Sandeep Kumar Gond
