冪等設計詳解

導讀

本文主要從研發人員的角度，結合研發人員日常常見的各類業務場景，從經典系統框架的每一層入手分析冪等處理的時機。希望透過這篇文章的分析，讓開發者在日常開發中對冪等的處理不再陌生。抓住導致請求、介面不冪等的本質，在工作中避免再陷入這個陷阱中。

冪等、冪等性這詞，作為一個研發人員是再熟悉不過的，那是否有深入思考過冪等產生的背景、為什麼需要冪等，如何做才是冪等的？今天將結合業務場景及請求的過程來分析解決冪等（性）的方法。

1 概念

冪等這個概念，是一個數學上的概念，即：f……(f(f(x))) = f(x)。用在計算機領域，指的是系統裡的介面或方法對外的一種承諾，使用相同引數對同一資源重複呼叫某個介面或方法的結果與呼叫一次的結果相同。

2 業務場景

從業務場景上來說，如：現在網際網路電商的下單服務，同一個使用者在短時間內呼叫某一個下單服務，只能下單成功一次；銀行賬戶之間的轉賬，A賬戶給B賬戶轉賬，無論系統出現什麼問題或故障，也只能轉賬成功一次；前端頁面對相同表單的內容多次向後端發起提交請求，後端只能給出一個相同的結果等都屬於冪等的範疇。

試想一下，如果提供的這些服務不是冪等的，客戶在下單時由於網路不穩定或是連續點了幾次下單按鈕，實際客戶只下了一單，結果系統裡給客戶生成了多單，那平臺/商家將是無法承受的，如果被“羊毛黨”盯上，損失是無可估量的；銀行之間的轉賬，A賬戶本來實際給B賬戶只轉了一百萬，結果B賬戶收到了幾百萬，這在業務上是不可接受的。分析這些業務場景，開發者發現，無論是下單服務、轉賬服務還是表單提交都是一個個業務請求，提供這些業務服務的介面或方法都應該保證無論服務是超時、重試或有故障等異常情況，都要滿足業務上的處理結果是正確的。業務上的一次或多次請求，最終的處理結果是一致的，即：在一定時間內，服務的冪等其實就是請求的冪等。

3 架構分析

從系統架構上進行分析，冪等該在哪一層去做，怎麼做？

圖1 經典系統框架圖

上圖為一個最常見的經典系統框架圖，Web端發起一個請求到後端，冪等該在哪一層來處理呢？不妨一層一層地分析。

Nginx是否需要做冪等，Nginx的主要功能是做Web伺服器、反向代理、負載均衡等，把請求轉發到後端的伺服器上，本身不參與具體的業務，所以Nginx是不需要做冪等處理的；Gateway是負責許可權校驗、安全防禦、認證鑑權、流量控制、協議轉換、日誌審計、監控等，本身也不含對任何業務的處理，所以其也不需要做冪等處理；Service層通常是對業務邏輯進行處理、編排，可能會改變資料，但對於資料的改變結果，最終也還是需要透過資料訪問層，寫入到資料庫，所以Service層也不需要做資料冪等；DAO層主要是和資料庫互動，把Service層的結果寫入資料庫，對Service層提供讀取、寫入資料庫的功能。

在寫入資料庫的時候，針對每一次的寫入，可能返回不同的結果，此時就需要按場景進行具體的分析對待；DataBase層，主要提供資料的儲存，並不參與具體的業務邏輯計算。所以，透過對該架構的每一層的功能分析，得出對於請求的冪等處理，需要在DAO層做處理，以便保證多次請求和一次請求的結果是一致的。

4 資料庫操作分析

透過上面的分析，得出冪等需要在DAO層來處理，再進一步分析，得出DAO層的操作主要就是CRUD。下面逐一對每一種操作分析是否需要做冪等，以及怎麼做。

R（read）：對應的操作SQL語句為select。只要查詢條件不變，在一定的時間內，執行一次和執行多次返回的結果肯定是相同的，所以其本身是冪等的，不需要再做處理。

select * from user where id = 1;

查詢一次或多次結果是一致的，所以是冪等的。

C（create）：對應的操作SQL語句為insert。此時，需要分情況，如果用到的資料庫主鍵為資料庫自增，不考慮業務主鍵防重的情況下，每一次寫入資料庫就不是冪等的，所以為了保證冪等，需要在資料insert前做業務防重或是在資料庫表上對業務主鍵加唯一索引。如果資料庫主鍵不是自增，是由業務系統寫入的，需要在業務系統裡把資料庫主鍵和業務主鍵做一對一對映，或是由獨立服務提供資料庫主鍵和業務主鍵的對映關係，保證多次請求獲取到的資料庫主鍵和業務主鍵是一致的，確保寫入資料庫操作是冪等的。綜合來說，就是相同的資料多次寫入資料庫後，能否保證只有一條資料。

insert into user (id,age,sex,ts) values(1,10,‘male’,2021-07-20 10:22:23);

U（update）：對應的操作SQL語句為update。更新操作時，一定是要用絕對值進行更新操作，而不要用相對值進行更新，相對值更新可能導致更新操作不冪等。

冪等：

update user set age = 10 where id = 1;

非冪等：

update user set age++ where id = 1;

D（delete）：對應的操作SQL語句為delete。刪除操作時，如果刪除的是一個範圍，生產上最好是禁止該類操作；比較推薦的做法是把按範圍操作刪除轉換為先按範圍查詢，再按查詢的主鍵進行刪除。而且按範圍刪除的操作不是冪等的。

冪等：

delete from user where id = 1;

非冪等：該類操作要禁止。

delete from user where id in （select id from user order by id desc limit 10);

5 常見業務場景

保證冪等的實現方式有多種，此處例舉幾類常見的業務場景，在實際應用中，根據業務場景進行選用。

圖2 頁面token機制處理流程

1. 前端頁面提交時，頁面token機制。進入頁面時，從伺服器獲取token，在伺服器端把token進行儲存，提交時把token帶到伺服器端進行驗證；常見的處理流程如下：
2. 樂觀鎖機制，使用資料庫的版本號實現樂觀鎖，資料庫更新時，判斷版本號是否與查詢時保持一致，一致更新成功，否則更新失敗；
3. select+insert，資料寫入前，先查詢資料是否存在，存在直接返回，不存在則寫入資料，保證寫入資料庫的資料正確性；常用於併發不高的一些後臺系統或是防止任務的重複執行；
4. 悲觀鎖機制，一般id為主鍵或唯一索引，僅鎖定當前記錄；
5. select * from table where id = '1234' for update;
6. 去重表，每一次寫入或更新業務表時，先查詢去重表是否已經存在記錄，再操作業務表。
7. 資料庫唯一索引，為業務表建立唯一索引，避免業務資料多次寫入；
8. 狀態機，業務狀態在變更之前是有條件的，必須按設定的狀態條件進行更新；

在實際開發中，保證提供的介面或服務的冪等（性），是一個最基本的技術要求，希望透過該分析，能對還未理解冪等（性）的研發人員有所幫助。