1. 基本概念

冪等性（Idempotence）是系統設計中經常提到的概念。

如果某個操作執行一次或多次都能產生相同的結果，那么它就是冪等的。

2. 代碼示例

下面這段代碼是冪等的。無論你調用多少次，show_my_button 的最終狀態都是False。

def hide_my_button(self):self.show_my_button = False

再看一個例子：

def toggle_my_button_visibility(self):self.show_my_button = not self.show_my_button

這個方法不是冪等的，因為每次調用都會翻轉狀態：第一次隱藏，第二次又顯示。

3. 常見誤區

3.1 冪等性與返回值無關

很多初學者會誤解冪等性，認為“多次調用返回值相同”才叫冪等。這是錯誤的，來看一個例子：

def hide_my_button(self):has_something_changed = self.show_my_buttonself.show_my_button = Falsereturn has_something_changed

如果第一次調用時 show_my_button 是 True，返回值是 True；再次調用時返回值變成了 False。但這個方法依然是冪等的，因為無論調用多少次，show_my_button 的最終狀態總是 False。冪等性關注的是操作的副作用或系統狀態的最終結果，而不是方法的返回值。

3.2 冪等與純函數

這兩個概念也容易混淆，所以簡單解釋一下。
純函數：給定相同的輸入，總是返回相同的輸出，且沒有任何副作用。

# 這是一個純函數。square(3) 將始終是相同的數字。
def square(my_number):return my_number ** 2# 這不是純函數。square(3) 幾乎不會產生相同的結果
def square_with_randomness(my_number):return (my_number ** 2) * random.uniform(0, 1)

冪等函數不一定是純函數。冪等函數可以有副作用:

# 如果每次保存相同的 name，最終數據庫的狀態保持一致 → 冪等
def save_name(name):my_database.save(name) # 寫入數據庫, 有副作用return name

4. 冪等性的問題

冪等設計也可能引入問題：如果某條“毒消息”導致消費者每次崩潰，那么該消息永遠留在隊列中。于是服務不斷重啟、崩潰、重試，形成死循環。
解決辦法：引入 死信隊列（DLQ），將處理失敗多次的消息轉移到 DLQ，以便后續人工排查。

5. 系統設計中的冪等性

在分布式系統中，網絡是不可靠的，服務會失敗，消息可能重復投遞，所以冪等性是保證數據一致性和系統健壯性的關鍵。以下場景都依賴冪等性：

• 消息隊列的重復消費
• RESTful API 請求重試
• 數據庫寫入與 UPSERT
• 分布式系統故障恢復

5.1 消息處理

假設我們有一個事件驅動系統：

• Service A 往消息隊列里推送事件
• Service B 消費這些事件（假設會執行一些計算操作）并寫入數據庫

如果Service B在計算過程中崩潰，或者Service B與數據庫之間存在網絡分區，或其他情況發生，那消息和事件將永遠丟失。

解決方案：不立即從隊列中刪除消息，而是等待Service B完成（包括寫入數據庫），然后再刪除消息。

但這帶來了一個新問題：同一條消息可能被讀取兩次。Service B執行計算并寫入數據庫，但隨后發生了一些情況（比如崩潰）。在消息從隊列中刪除之前，服務已經崩潰。會發生什么？當 Service B 重啟后，將繼續從最后那條消息開始消費，因此該消息被消費了兩次！但這并不成問題，如果 Service B 的處理邏輯是冪等的，那么即使消息被重復消費，最終結果也是一致的。

缺點是需要一些額外的復雜性（需要保證操作冪等）和一些計算資源（可能不必要地多次執行相同操作）。但這些缺點和丟失消息比起來不值一提。

5.2 API

如果你正在構建REST API，其實已經在處理冪等性了。HTTP協議實際上定義了哪些方法應該是冪等的：

HTTP 方法	冪等性	說明
GET	是	查詢資源，多次調用結果相同
PUT	是	完全替換資源，重復 PUT 沒有副作用
DELETE	是	刪除資源，刪除已不存在的資源結果也相同
POST	否	通常用于創建資源，天然非冪等

POST請求：通常在設計上不是冪等的。每個POST通常創建某些內容。但你可以使用冪等鍵使它們冪等。其工作原理如下：隨請求發送一個唯一ID（通常在頭中），服務器記住"已經處理過這個ID，因此將返回相同的結果，而不是再次執行工作"。

def create_user(request):idempotency_key = request.headers.get('Idempotency-Key')# 是否已經處理過這個確切的請求？if idempotency_key and already_processed(idempotency_key):return get_cached_response(idempotency_key)# 沒有，創建用戶user = User.create(request.data)# 緩存響應以備下次使用if idempotency_key:cache_response(idempotency_key, user)return user

5.3 數據庫

在數據庫操作中，常用的冪等性設計包括：

UPSERT操作（如果存在則INSERT或UPDATE）自然是冪等的。使用相同數據運行update 10次，每次都會得到相同的結果。記錄要么創建一次，要么多次更新為相同的值。

5.4 分布式系統

在分布式系統中，冪等性是重試機制的安全基礎。

• 網絡調用失敗可能導致請求被重發
• 微服務之間的鏈路存在超時重試
• 跨機房、跨服務調用可能會收到重復事件

如果操作不是冪等的，每次重試可能引入數據污染和狀態異常。

6. 完整示例：訂單處理系統

下面通過一個具體示例將所有內容整合起來。有一個簡單的訂單處理流水線：訂單來自Web應用程序，由訂單服務驗證，進入隊列，然后由訂單處理器服務處理并寫入數據庫。

• Web App → 提交訂單請求
• API Gateway → 路由、鑒權、限流
• Order Service → 校驗訂單并發送消息到 MQ
• MQ → 存儲訂單消息
• Order Processor Service → 消費消息并寫入數據庫
• Orders DB → 持久化訂單數據
• Dead-Letter Queue → 收集失敗的消息
• Notification Service → 給用戶發送通知

這里的關鍵是 Order Service 要是冪等的。怎么使Order Service冪等？

Order Service從 MQ 消費消息并執行實際的業務邏輯。當處理消息（即訂單事件）時，我們希望：

1. 檢查它是否已被處理
2. 如果沒有，將其插入Orders DB，告知Notification Service發送通知

這是冪等的，因為已經檢查它是否已被處理。可以通過在訂單表中執行SELECT操作，僅當不存在時才插入。可以對通知服務執行類似操作，或在通知服務內部使用其自己的數據庫執行。

注意需要處理并發問題（有兩個不同的訂單處理服務實例處理同一條消息，并且它們同時執行SELECT），處理消息兩次不是一個合理的做法，更好的方案是將此邏輯包裝到事務中。