冪等性在我們的作業中無處不在，無論是支付場景還是下訂單等核心場景都會涉及，也是分布式系統最常遇到的問題，除此之外，也是大廠面試的重災區，
知道了冪等性的重要性，下面我就詳細介紹冪等性以及具體的解決方案，希望對大家有所幫助@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|分布式|高并發|架構師
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/501465.html
標籤：其他
上一篇：單例模式
下一篇：單例模式