冪等性在我們的工作中無處不在，無論是支付場景還是下訂單等核心場景都會涉及，也是分散式系統最常遇到的問題，除此之外，也是大廠面試的重災區。 知道了冪等性的重要性，下麵我就詳細介紹冪等性以及具體的解決方案，希望對大家有所幫助@mikechen 什麼是冪等性 冪等是一個數學與電腦學概念，在數學中某一元運 ...
冪等性在我們的工作中無處不在，無論是支付場景還是下訂單等核心場景都會涉及，也是分散式系統最常遇到的問題，除此之外，也是大廠面試的重災區。
知道了冪等性的重要性，下麵我就詳細介紹冪等性以及具體的解決方案，希望對大家有所幫助@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 不匹配就返回重覆執行的錯誤信息，這樣來保證冪等操作。
上面我只是列舉瞭解決冪等性的解決方案與思路，其實還有很多類似解決方案，比如訂單流程還可以結合前段攔截，以及更多的後端方案來保障唯一性。
這些還需要結合你的實際業務場景，來最終來選擇更適合你的解決方案，但是萬變不離其中，都是為了保證一次操作，保證唯一約束，這才是冪等性的本質。
以上！
作者簡介
mikechen,10年+大廠架構經驗，《BAT架構技術500期》系列文章作者，曾就職於阿裡、淘寶、百度等一線互聯網大廠。 閱讀mikechen的互聯網架構更多技術文章合集 Java併發|JVM|MySQL|Spring|Redis|分散式|高併發|架構師
