什麼是冪等性？四種介面冪等性方案詳解！

冪等性在我們的工作中無處不在，無論是支付場景還是下訂單等核心場景都會涉及，也是分散式系統最常遇到的問題，除此之外，也是大廠面試的重災區。

知道了冪等性的重要性，下面我就詳細介紹冪等性以及具體的解決方案，希望對大家有所幫助 @mikechen

什麼是冪等性

冪等是一個數學與計算機學概念，在數學中某一元運算為冪等時，其作用在任一元素兩次後會和其作用一次的結果相同。

所謂介面冪等性，就是一次和多次請求某一個資源對於資源本身應該具有同樣的結果。

也就是說，在介面重複呼叫的情況下，對系統產生的影響是一樣的，這就是冪等性。

 

為什麼需要冪等性

業務開發中，經常會遇到重複提交的情況，無論是由於網路問題無法收到請求結果而重新發起請求，或是前端的操作抖動而造成重複提交情況。

在交易系統，支付系統這種重複提交造成的問題有尤其明顯，比如：使用者在 APP 上連續點選了多次提交訂單，後臺應該只產生一個訂單。

再比如：向支付寶發起支付請求，由於網路問題或系統 BUG 重試，支付寶應該只扣一次錢，而不是多次重試，造成多次扣錢。

再比如：現在是微服務的時代，服務化介面在外部呼叫者會存在多次呼叫的情況 (考慮網路中斷重試等)，為了防止外部多次呼叫對系統資料狀態的發生多次改變，將服務設計成冪等，就是為了防止多次重試，造成系統不一致的問題。

透過以上典型的支付場景就知道冪等性的重要性了，那問題來了，如何實現冪等性，有哪些解決方案？下面我們接著聊。

 

冪等性的解決方案

資料庫唯一主鍵

資料庫唯一主鍵的實現主要是利用資料庫中主鍵唯一約束的特性，一般來說唯一主鍵比較適用於 “插入” 時的冪等性，其能保證一張表中只能存在一條帶該唯一主鍵的記錄。

唯一索引 使用唯一索引可以避免髒資料的新增，當插入重複資料時資料庫會拋異常，保證了資料的唯一性。

唯一索引表的建立示例如下：

CREATE TABLE `table_name` (
  `id` int NOT NULL AUTO_INCREMENT,
  `orderid` varchar(32) NOT NULL DEFAULT '' COMMENT '唯一id',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uq_orderid` (`orderid`) COMMENT '唯一約束') ENGINE=InnoDB;

使用資料庫唯一主鍵完成冪等性時需要注意的是，該主鍵一般來說並不是使用資料庫中自增主鍵，而是使用分散式 全域性 ID 充當主鍵，這樣才能能保證在分散式環境下 ID 的全域性唯一性。

適用操作：

• 插入操作
• 刪除操作

 

資料庫樂觀鎖

資料庫樂觀鎖方案一般只能適用於執行 “更新操作” 的過程，我們可以提前在對應的資料表中多新增一個欄位，充當當前資料的版本標識。

這樣每次對該資料庫該表的這條資料執行更新時，都會將該版本標識作為一個條件，值為上次待更新資料中的版本標識的值。

select version from tablename where xxx

更新資料時首先和版本號作對比，如果不相等說明已經有其他的請求去更新資料了，提示更新失敗。

update tablename set count=count+1,version=version+1 where version=#{version}

適用操作：

• 更新操作

 

PRG 模式

Post/Redirect/Get 是一種 web 開發設計模式，用於防止表單的重複提交。

預設情況，提交 Post 請求到伺服器後，如果直接重新整理瀏覽器，會重新在提交一次 Post 請求。

在訪問電商網站時，提交訂單採用的是 Post 請求，如果直接重新整理瀏覽器就容易導致重複訂單的提交，這個不是使用者希望發生的行為。

PRG 方法就是使用者防止這種現象的發生，下面例圖描述了用 PRG 方法來避免 Post 請求的重複提交。當伺服器處理完 Post 請求後，會發響應給使用者瀏覽器，指示使用者瀏覽器用 Get 方式立刻訪問另一條 URL 。使用者瀏覽器拿到 Get 請求的資料，整個流程才算結束。

此時使用者重新整理當前頁面，也不會引起 Post 請求的重複提交了。

 

防重 Token 令牌

針對客戶端連續點選或者呼叫方的超時重試等情況，例如提交訂單，此種操作就可以用 Token 的機制實現防止重複提交。

簡單的說就是呼叫方在呼叫介面的時候先向後端請求一個全域性 ID（Token），請求的時候攜帶這個全域性 ID 一起請求（Token 最好將其放到 Headers 中），後端需要對這個 Token 作為 Key，使用者資訊作為 Value 到 Redis 中進行鍵值內容校驗，如果 Key 存在且 Value 匹配就執行刪除命令，然後正常執行後面的業務邏輯。

如果不存在對應的 Key 或 Value 不匹配就返回重複執行的錯誤資訊，這樣來保證冪等操作。

上面我只是列舉了解決冪等性的解決方案與思路，其實還有很多類似解決方案，比如訂單流程還可以結合前段攔截，以及更多的後端方案來保障唯一性。

這些還需要結合你的實際業務場景，來最終來選擇更適合你的解決方案，但是萬變不離其中，都是為了保證一次操作，保證唯一約束，這才是冪等性的本質。

以上！

作者簡介

---