最近很多人都在談論冪等性，好吧，這回我也來聊聊這個話題，光看著倆字，一開始的確有點一頭霧水，語文不好嘛，詞太專業嘛，對吧
現如今我們的系統大多拆分為分布式soa，或者微服務，一套系統中包含了多個子系統服務，而乙個子系統服務往往會去呼叫另乙個服務，而服務呼叫服務無非就是使用rpc通訊或者restful，既然是通訊，那麼就有可能再伺服器處理完畢後返回結果的時候掛掉，這個時候使用者端發現很久沒有反應，那麼就會多次點選按鈕，這樣請求有多次，那麼處理資料的結果是否要統一呢？那是肯定的！尤其再支付場景。
冪等性：就是使用者對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點選而產生了***。舉個最簡單的例子，那就是支付，使用者購買商品使用約支付，支付扣款成功，但是返回結果的時候網路異常，此時錢已經扣了，使用者再次點選按鈕，此時會進行第二次扣款，返回結果成功，使用者查詢餘額返發現多扣錢了，流水記錄也變成了兩條．．．
在以前的單應用系統中，我們只需要把資料操作放入事務中即可，發生錯誤立即回滾，但是再響應客戶端的時候也有可能出現網路中斷或者異常等等。
在增刪改查4個操作中，尤為注意就是增加或者修改，
查詢對於結果是不會有改變的，
刪除只會進行一次，使用者多次點選產生的結果一樣
修改在大多場景下結果一樣
增加在重複提交的場景下會出現
那麼如何設計介面才能做到冪等呢？
方法一、單次支付請求，也就是直接支付了，不需要額外的資料庫操作了，這個時候發起非同步請求建立乙個唯一的ticketid，就是門票，這張門票只能使用一次就作廢，具體步驟如下：
非同步請求獲取門票
呼叫支付，傳入門票
根據門票id查詢此次操作是否存在，如果存在則表示該操作已經執行過，直接返回結果；如果不存在，支付扣款，儲存結果
返回結果到客戶端
如果步驟4通訊失敗，使用者再次發起請求，那麼最終結果還是一樣的
方法二、分布式環境下各個服務相互呼叫
這邊就要舉例我們的系統了，我們支付的時候先要扣款，然後更新訂單，這個地方就涉及到了訂單服務以及支付服務了。
使用者呼叫支付，扣款成功後，更新對應訂單狀態，然後再儲存流水。
而在這個地方就沒必要使用門票ticketid了，因為會比較閒的麻煩
（支付狀態：未支付，已支付）
步驟：1、查詢訂單支付狀態
2、如果已經支付，直接返回結果
3、如果未支付，則支付扣款並且儲存流水
4、返回支付結果
如果步驟4通訊失敗，使用者再次發起請求，那麼最終結果還是一樣的
對於做過支付的朋友，冪等，也可以稱之為沖正，保證客戶端與服務端的交易一致性，避免多次扣款。
最後來看一下我們的訂單流程，雖然不是很複雜，但是最後在支付環境是一定要實現冪等性的
分布式 冪等性
現在你的服務提供一些外部介面呼叫，然後你這個服務又是部署在多台機器上的，然後前端在操作的時候正好呼叫了請求，假如我們的業務功能是扣款，然後在負載均衡的時候你的請求被傳送到不同的機器上，所以你需要保證的就是同樣的一次請求只能成功一次，另外的需要丟棄調。那麼如何保證分布式環境下的冪等性呢？保證冪等性主要...
分布式系統冪等性詳解
冪等 idempotent idempotence 是乙個數學與計算機學概念，常見於抽象代數中。在程式設計中.乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。這些函式不會影響系統狀態，也不用擔心重複執行...
分布式系統 冪等性設計
web資源或api方法的冪等性是指一次和多次請求某乙個資源應該具有同樣的 冪等性是系統的介面對外一種承諾 而不是實現 承諾只要呼叫介面成功,外部多次呼叫對系統的影響是一致的。冪等性是分布式系統設計中的乙個重要概念，對超時處理 系統恢復等具有重要意義。宣告為冪等的介面會認為外部呼叫失敗是常態,並且失敗...