隨著微服務與云原生技術的普及，分布式系統已成為現代軟件架構的主流。然而，系統的分布式特性也帶來了新的挑戰，尤其是在網絡延遲、請求重試、并發操作等復雜場景下，如何保證數據的一致性、操作的正確性以及服務的可用性，成為了系統設計的核心難點。本文將介紹分布式架構下的2個關鍵穩定性保障機制：請求防重和接口冪等性。

1、分布式請求防重策略與技術

在分布式環境中，由于客戶端重試、網絡抖動、網關超時重發或消息隊列的重投機制，同一個請求可能會多次到達服務端。請求防重的核心目標是識別并丟棄這些重復的請求，確保一個業務邏輯在面對完全相同的多次請求時，僅被有效執行一次。這不僅可以避免數據冗余和錯誤，也是實現接口冪等性的重要前提。

1.1 唯一請求ID與防重表

這是一種基于數據庫或持久化存儲的強一致性防重方案，其核心思想是為每一次業務操作生成一個全局唯一的標識符，并在處理前進行校驗。

在技術實現上要求調用方在發起請求時，攜帶一個全局唯一的請求ID。服務端在接收到請求后，首先會嘗試將這個請求ID插入到一個專用的“防重表”中。這個表的關鍵在于為請求ID字段設置了唯一性約束。具體流程如下：

• 生成ID：客戶端或上游服務在發起寫操作請求前，生成一個全局唯一的request_id。
• 攜帶ID請求：客戶端將request_id連同業務參數一同發送至服務端。
• 原子化插入校驗：服務端在執行核心業務邏輯之前，嘗試執行INSERT INTO deduplication_table (request_id) VALUES (?)。
• 結果判斷與處理：a) 如果插入成功，說明這是一個新的請求。服務端繼續執行后續的業務邏輯。b) 如果插入失敗并拋出唯一鍵沖突的異常，則證明該request_id已被處理過。服務端捕獲此異常，識別為重復請求，直接丟棄或返回先前處理的結果，不再執行業務邏輯 。

圖片

該技術的優勢是在于其極高的可靠性，能夠利用數據庫的ACID特性，從根本上保證數據操作的唯一性。缺點就是每次請求都需要進行一次數據庫寫入操作，那么數據庫容易成為整個系統的性能瓶頸，尤其是在高并發場景下 。同時，需要考慮防重表的清理機制，以避免其無限增長。通常不會單獨設計防重表，而是在表設計的時候定義唯一鍵做防重。

1.2 分布式鎖

分布式鎖可以有效控制并發，通過確保在分布式系統的多個節點中某個關鍵代碼塊在同一時間只能被一個線程執行，從而間接實現請求防重。

實現原理也很簡單，當請求到達時，服務端會根據請求中的業務關鍵信息組合成一個唯一的鎖key。然后，服務嘗試去獲取這個key對應的分布式鎖。具體流程如下：

• 構造鎖Key：服務端根據請求參數生成一個唯一的鎖標識，例如 lock:payment:order_id_123。
• 嘗試加鎖： 服務嘗試使用Redis的SETNX命令或Zookeeper的臨時節點等機制來獲取該鎖 。
• 結果判斷與處理：a) 如果成功獲取鎖，表明當前沒有其他請求在處理此項業務。服務端開始執行業務邏輯，并在完成后釋放鎖。b) 如果獲取鎖失敗，則說明已有另一個線程或進程正在處理，當前請求被視為重復，應立即返回或丟棄

分布式鎖的核心優勢在于控制并發，特別適合“處理中”狀態的防重，防止對同一資源的并發修改。技術實現上可以通過Redis，也可以通過Zookeeper的臨時節點完成。但其缺點是增加了系統的復雜性，需要處理鎖的超時、續期和安全釋放等問題，否則可能導致死鎖。鎖的粒度設計也至關重要，過大的粒度會降低系統吞吐量。

1.3 令牌機制

令牌機制主要用于防止客戶端因用戶誤操作（如快速點擊提交按鈕）或前端邏輯不完善導致的表單重復提交。在實現上分為兩個階段：獲取令牌和使用令牌。服務端為即將發生的寫操作預先生成一個一次性的、唯一的令牌。具體流程如下：

1. 申請令牌：用戶訪問表單頁面時，客戶端向服務端發起一個獲取令牌的請求。
2. 頒發并存儲令牌：服務端生成一個唯一Token（如UUID），將其存儲在Redis等高速緩存中并設置較短的過期時間，然后將Token返回給客戶端 。客戶端通常將此Token存放在表單的隱藏域中。
3. 提交時攜帶令牌：用戶提交表單時，請求中必須攜帶此Token。
4. 原子化驗簽與銷毀：服務端接收請求后，會使用原子操作（如Redis+Lua腳本）來驗證并刪除該Token。a) 如果Token存在且被成功刪除，則處理業務邏輯。b) 如果Token不存在（已被其他請求消耗或已過期），則判定為重復提交，拒絕處理 。

圖片

令牌機制能有效攔截來自前端的重復請求，實現簡單。但它要求前端進行配合，增加了前后端的交互次數。

1.4 狀態機約束

對于有明確生命周期和狀態流轉的業務對象（如訂單、工單），可以利用狀態機模型來實現防重。其核心思想是業務操作必須遵循預設的狀態流轉路徑。任何不符合當前狀態的遷移動作都被視為非法或重復操作。具體流程如下：

• 定義狀態：為業務對象定義清晰的狀態集（如訂單狀態：待支付、已支付、已發貨、已完成、已取消）。
• 接收操作請求：服務端接收到一個改變狀態的請求，例如“支付訂單”。
• 校驗當前狀態：在執行操作前，從數據庫或緩存中讀取訂單的當前狀態。
• 判斷狀態遷移合法性：a) 如果當前訂單狀態是“待支付”，則“支付”操作是合法的。服務端繼續執行支付邏輯，并將狀態更新為“已支付”。為了防止并發下的狀態沖突，通常會結合樂觀鎖（版本號）進行更新。b) 如果當前訂單狀態已經是“已支付”，則再次收到的“支付”請求就是重復請求，應直接拒絕 。

狀態機方案與業務邏輯緊密結合，邏輯清晰，實現優雅且非?？煽?。它不僅能防重，還能保證業務流程的正確性。其主要局限在于適用場景，僅限于那些可以被清晰地建模為有限狀態機的業務流程。

2、分布式接口冪等性實現策略與技術

冪等性是一個數學概念，是指一個操作無論執行一次還是執行多次，其產生的影響和結果都是相同的。在分布式系統中，由于網絡不可靠導致的重試是常態，保證寫操作的冪等性對于避免數據錯亂、資金損失等嚴重問題至關重要。

2.1 數據庫唯一約束

通過在數據庫表上為能夠唯一標識業務的字段（或字段組合）建立唯一索引，來利用數據庫自身的機制阻止重復數據的插入。具體流程如下：

• 識別唯一業務鍵：在設計表結構時，確定一個能唯一標識一筆交易或一個實體的字段。
• 創建唯一索引：為該字段創建UNIQUE INDEX。
• 執行插入操作：當服務需要創建一個新記錄時，直接執行INSERT。
• 處理執行結果：a) 第一次請求，INSERT成功，數據被創建。b) 后續的重試請求，由于transaction_id已存在，INSERT會失敗，數據庫返回唯一鍵沖突錯誤。應用層捕獲此錯誤后，即可判定這是一個重復的創建操作，從而保證了“創建”這一行為的冪等性 。

圖片

該方案簡單、高效，且保證了最終一致性，但它主要適用于INSERT場景。對于UPDATE操作，需要借助其他策略。同時，在高并發寫入場景下，唯一索引的沖突檢查可能會對數據庫性能造成一定壓力。

2.2 樂觀鎖/版本號機制

樂觀鎖是實現UPDATE操作冪等性的經典方案。它假設在操作期間數據不會被其他事務所修改，直到提交時才進行檢查。該策略通常通過在數據表中增加一個version（版本號）或timestamp（時間戳）字段來實現。具體流程如下：

• 讀取數據與版本號：SELECT data, version FROM my_table WHERE id = ?;。
• 執行業務計算：在內存中根據讀取的data進行業務邏輯計算。
• 帶版本號更新：提交更新時，在UPDATE語句的WHERE子句中加入對版本號的檢查：UPDATE my_table SET data = ‘new_data’, version = version + 1 WHERE id = ? AND version = ‘old_version’;。
• 檢查更新結果：a) 如果UPDATE影響的行數為1，說明在操作期間沒有其他請求修改過數據，更新成功。b) 如果影響的行數為0，說明version已被其他請求改變，當前操作基于的是舊數據。此時，可以判定為冪等沖突（或并發沖突），應放棄本次修改或重新讀取數據重試 。

圖片

樂觀鎖避免了悲觀鎖長時間的資源鎖定，因此在高并發讀多寫少的場景下有很好的性能表現。它能有效解決UPDATE操作的冪等問題。缺點是增加了業務邏輯的復雜性，應用層需要處理更新失敗后的重試邏輯。

2.3 全局冪等令牌

該策略將冪等校驗邏輯與業務邏輯解耦，適用于INSERT、UPDATE和DELETE等多種操作。這里的令牌代表的是一個完整的業務操作，而不僅僅是一次HTTP提交。

• 生成令牌：調用方（客戶端或其他服務）在發起一個需要保證冪等的業務操作前，需生成一個全局唯一的冪等令牌idempotency_key。
• 攜帶令牌請求：將idempotency_key通過請求頭或請求體傳遞給服務端。
• 原子化檢查與鎖定：服務端收到請求后，以idempotency_key為鍵，使用原子命令（如Redis的SET key value NX EX）嘗試在共享緩存中創建一個占位記錄。
• 處理流程：a) 首次請求：SET成功，表明這是此idempotency_key的第一次請求。服務開始執行業務邏輯。執行完畢后，可以將執行結果存入緩存，與idempotency_key關聯，并為該key設置一個更長的過期時間 。b) 重試請求：SET失敗，表明該idempotency_key已存在。服務端可以直接從緩存中查詢并返回上一次的執行結果，從而保證了冪等性 。

圖片

該方案非常靈活，不侵入核心業務表的結構，且能夠通過返回緩存結果來優化重試請求的體驗。它依賴于一個高可用的分布式緩存系統（如Redis）。令牌的生成、傳遞和存儲管理也引入了額外的系統復雜性

2.4 狀態機流轉控制

通過嚴格控制業務實體的狀態流轉，確保操作只能在特定狀態下執行，從而實現冪等。這與防重部分的狀態機原理一致，但在冪等性語境下，更強調操作對最終狀態的影響是唯一的。一個操作是否執行，取決于業務實體當前的狀態是否允許該操作發生。

• 加載實體與狀態：接收到操作請求后，加載業務實體及其當前狀態。
• 驗證狀態轉移：根據預定義的狀態機模型，判斷當前狀態是否允許執行請求的操作。例如，只有在“待發貨”狀態下，才能執行“發貨”操作。
• 執行與狀態更新：a) 如果狀態轉移合法，則執行業務操作，并原子性地（通常結合樂觀鎖）將實體更新到下一個狀態。b) 如果狀態轉移非法，則直接拒絕操作，返回錯誤信息。因為無論多少次非法的操作請求，都不會改變實體的當前狀態，從而保證了冪等性 。

狀態機是與業務領域模型高度耦合的冪等實現方式，邏輯嚴謹，一旦模型建立，冪等性就有了天然的保障。其缺點是適用范圍有限，主要用于具有明確、有限狀態的業務流程。對于無狀態的通用接口，此方法不適用。

分布式系統的健壯性需要將防重和冪等作為架構設計的核心考量。請求防重是數據正確性的保障，通過唯一ID、分布式鎖、令牌和狀態機等手段，可以有效過濾掉意外的重復請求；接口冪等性保證了在不可靠網絡環境下，利用數據庫約束、樂觀鎖、全局令牌和狀態機，可以確保重試操作不會產生非預期的副作用。