web資源或api方法的冪等性是指一次和多次請求某乙個資源應該具有同樣的***。冪等性是系統的介面對外一種承諾(而不是實現), 承諾只要呼叫介面成功, 外部多次呼叫對系統的影響是一致的。冪等性是分布式系統設計中的乙個重要概念，對超時處理、系統恢復等具有重要意義。宣告為冪等的介面會認為外部呼叫失敗是常態, 並且失敗之後必然會有重試。例如，在因網路中斷等原因導致請求方未能收到請求返回值的情況下，如果該資源具備冪等性，請求方只需要重新請求即可，而無需擔心重複呼叫會產生錯誤。實際上，我們常用的http協議的方法是具有冪等性語義要求的，比如：get方法用於獲取資源，不應有***，因此是冪等的；post方法用於建立資源，每次請求都會產生新的資源，因此不具備冪等性；put方法用於更新資源，是冪等的；delete方法用於刪除資源，也是冪等的。
1.mvcc方案
多版本併發控制，該策略主要使用update with condition（更新帶條件來防止）來保證多次外部請求呼叫對系統的影響是一致的。在系統設計的過程中，合理的使用樂觀鎖，通過version或者updatetime（timestamp）等其他條件，來做樂觀鎖的判斷條件，這樣保證更新操作即使在併發的情況下，也不會有太大的問題。例如12
select*fromtablenamewherecondition=#condition#//取出要跟新的物件，帶有版本versoin
update tablenamesetname=#name#,version=version+1whereversion=#version#
在更新的過程中利用version來防止，其他操作對物件的併發更新，導致更新丟失。為了避免失敗，通常需要一定的重試機制。
2.去重表
在插入資料的時候，插入去重表，利用資料庫的唯一索引特性，保證唯一的邏輯。
3.悲觀鎖
select for update，整個執行過程中鎖定該訂單對應的記錄。注意：這種在db讀大於寫的情況下盡量少用。
4. select + insert
併發不高的後台系統，或者一些任務job，為了支援冪等，支援重複執行，簡單的處理方法是，先查詢下一些關鍵資料，判斷是否已經執行過，在進行業務處理，就可以了。注意：核心高併發流程不要用這種方法。
5.狀態機冪等
在設計單據相關的業務，或者是任務相關的業務，肯定會涉及到狀態機，就是業務單據上面有個狀態，狀態在不同的情況下會發生變更，一般情況下存在有限狀態機，這時候，如果狀態機已經處於下乙個狀態，這時候來了乙個上乙個狀態的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態機的冪等。
6. token機制，防止頁面重複提交
業務要求：頁面的資料只能被點選提交一次
發生原因：由於重複點選或者網路重發，或者nginx重發等情況會導致資料被重複提交
解決辦法：
處理流程：
token特點:要申請，一次有效性，可以限流
7. 對外提供介面的api如何保證冪等
總結： 冪等性應該是合格程式設計師的乙個基因，在設計系統時，是首要考慮的問題，尤其是在像支付寶，銀行，網際網路金融公司等涉及的都是錢的系統，既要高效，資料也要準確，所以不能出現多扣款，多打款等問題，這樣會很難處理，使用者體驗也不好 。
分布式系統面試 冪等性設計
分布式服務介面的冪等性如何設計 比如不能重複扣款 從這個問題開始，面試官就已經進入了實際的生產問題的面試了。乙個分布式系統中的某個介面，該如何保證冪等性？這個事兒其實是你做分布式系統的時候必須要考慮的乙個生產環境的技術問題。啥意思呢？你看，假如你有個服務提供乙個介面，結果這服務部署在了 5 臺機器上...
分布式 冪等性
現在你的服務提供一些外部介面呼叫，然後你這個服務又是部署在多台機器上的，然後前端在操作的時候正好呼叫了請求，假如我們的業務功能是扣款，然後在負載均衡的時候你的請求被傳送到不同的機器上，所以你需要保證的就是同樣的一次請求只能成功一次，另外的需要丟棄調。那麼如何保證分布式環境下的冪等性呢？保證冪等性主要...
分布式系統冪等性詳解
冪等 idempotent idempotence 是乙個數學與計算機學概念，常見於抽象代數中。在程式設計中.乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。這些函式不會影響系統狀態，也不用擔心重複執行...