假如有個服務提供乙個介面（服務部署在多個服務機器），接著有個介面是付款介面。使用者在前端上操作的時候，乙個訂單不小心發起了兩次支付請求，然後這兩個請求分散在了這個服務部署的不同的機器上，結果乙個訂單扣款扣兩次。這樣的場景，就是介面沒***冪等性的結果。
保證冪等性的核心
1.對於每個請求必須有乙個唯一的標識。
2.每次處理完請求之後，必須有乙個記錄標識這個請求處理過了。
3.每次接收請求需要進行判斷之前是否處理過的邏輯處理。
常見解決方案
1.業務表內唯一索引
如果要對建立銷售出庫單的介面保證冪等性，也就是說人家網路超時，重複呼叫的時候，保證乙個訂單只能有乙個對應的銷售出庫單。針對銷售出庫單的表的訂單id，建立乙個唯一索引，你如果介面被重試，同乙個訂單建立乙個銷售出庫單的話，一定會違反唯一索引，那麼此時會報錯。
2.業務表內狀態機
修改訂單狀態，比如說將訂單狀態修改為【待發貨】的時候，訂單的狀態其實就變為了【待發貨】。
updateorder
set status =
'待發貨
'where status =
'待付款
'and id =
1;
這時候如果id為1的訂單介面被重複呼叫了，即使再執行一次這個操作也不會有效果，因為這時候該訂單記錄的狀態字段已經改變了，sql並不會命中該記錄。
在這種業務場景中也是通常都會有邏輯判斷的，比如當前是否處於某個狀態，然後才能流轉到下乙個狀態（狀態為待付款的才能流轉到待發貨）。
3.基於版本號的更新
idname
ageversion
1yanggb181
給業務表內新增乙個版本號的字段，如果要呼叫乙個介面去更新年齡之前，就需要先查一下他的版本號是多少，然後呼叫介面的時候帶上版本號。
在介面裡保證分布式介面的冪等性（在更新的sql中新增version的條件判斷）：
updateuser
set age =
21, version = version +
1where id =
1and version =
1;
這樣，多次提交的請求，因為版本號（version）都一樣，因為第一次請求執行成功之後version已經+1了，則後面的請求因為version對應不上，都不會被執行。
4.基於mysql的去重表 / 基於redis的去重
比如說介面方法為changeage(1, 21, 1)，可以將所有的引數拼接成乙個字串，或者是從這些入參裡選擇一些引數（可以唯一標識這一次請求的一些引數），每次請求進來，在操作之前先校驗這個字串，如果校驗通過則繼續執行操作，校驗失敗則跳過。
如果基於mysql，可以單獨搞乙個表出來（可以就乙個字段），在這個表上的乙個欄位建乙個唯一索引，插入的記錄值就是前面拼接的字串。因為第一次請求到達的時候，這個字串在表中還不存在對應的記錄，則會往表中插入該記錄，並繼續執行業務邏輯。後面的請求再到達的時候，因為這個字串在表中已經存在了對應的記錄了，唯一索引就會報乙個衝突出來，這次插入就會失敗，後續的業務邏輯也就會跳過執行了。
如果介面呼叫量很大，併發很高，還可以選擇使用redis。同樣是拼接乙個字串串出來，直接set設定到redis裡去，如果下一次請求再過來，會發現這個key已經存在了，那麼這個時候就不能執行了，因為已經可以知道出現了重複呼叫的情況了。
冪等的缺點
冪等是為了簡化客戶端邏輯處理，但是卻增加了服務提供者的邏輯和成本，是否有必要在系統中引入冪等，需要根據具體場景具體分析，因此除了業務上的特殊要求外，一般建議是盡量不提供冪等的介面。
1.增加了額外控制冪等的業務邏輯，複雜化了業務功能。
2.把並行執行的功能改為序列執行，降低了執行效率。
"人不能太深情得活著，也不能總是追緬過去。"
冪等性解決方案
1 token方案，前端請求時服務端生成乙個token給前端，在這個請求沒處理完時這個token永遠生效，在這個過程中如果前端重複請求，服務端判斷這個token，如果發現是同乙個則不予理睬，請求處理完畢後釋放token 2 利用mysql行鎖 前端進入某個頁面自己生成乙個唯一標識，給服務端傳過來，服...
保證介面冪等性
冪等性 其實就是資料一致性和事務完整性 數學上的定義 f f x f x x被函式f作用一次和作用無限次的結果是一樣的。冪等性應用在軟體系統中，可以把它簡單定義為 某個函式或者某個介面使用相同引數呼叫一次或者無限次，其造成的後果是一致的，在實際應用中一般針對於介面進行冪等性設計。例如 冪等需要通過唯...
什麼是冪等性解決方案
今天看到一篇講冪等的文章，想起來上次面試的時候有問過，記錄一下，加深印象。首先說一下冪等的概念，官方一點的說法是 在程式設計中乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。其實可以簡單理解為多次操作和一次操作的結果是一樣的。一般情況下介面正常呼叫的時候返回資訊不會重複提交，但...