## 冪等性定義 **冪等性是系統服務對外一種承諾，承諾只要調用接口成功，外部多次調用對系統的影響是一致的。冪等性并不是所有的接口都需要的。** 如果把操作按照功能分類，那就是增刪改查四種，在 http 協議中則表現為 Get、Post、Put、Delete * Get 方法用于獲取資源，不應當對系統資源進行改變，所以是冪等的。 * Delete 方法用于刪除資源，雖然改變了系統資源，但是第一次和第N次刪除操作對系統的作用是相同的，所以是冪等的。 * 修改操作有可能是冪等的也可能不冪等。 * Post 新增操作天生就不是一個冪等操作，其在 http 協議的定義如下： > The POST method is used to request that the origin server accept the entity enclosed in the request as a **new subordinate**of the resource identified by the Request-URI in the Request-Line. ## 怎么出現的 1. 前端重復提交：提交訂單，用戶快速重復點擊多次，造成后端生成多個內容重復的訂單。 2. 接口超時重試：對于給第三方調用的接口，為了防止網絡抖動或其他原因造成請求丟失，這樣的接口一般都會設計成超時重試多次。 3. 消息重復消費：MQ消息中間件，消息重復消費。 ## 如何解決 1. token機制  2. 狀態機 主要思路就是通過狀態標識的變更，保證業務中每個流程只會在對應的狀態下執行，如果標識已經進入下一個狀態，這時候來了上一個狀態的操作就不允許變更狀態，保證了業務的冪等性。 比如訂單支付成功后，就把訂單標識為修改為支付成功，現在再次調用訂單支付或者取消接口，會先判斷訂單狀態標識，如果是已經支付過或者取消訂單，就不會再次支付了。 3. 唯一ID，比如訂單號  ## 總結 通過以上的了解我們可以知道，唯一id是一個更好的解決方式。 冪等性是開發當中很常見也很重要的一個需求。尤其是金融、支付等行業對其要求更加嚴格，既要有好的性能也要有嚴格的冪等性。除了對其概念的掌握，理解自身業務需求更是實現冪等功能的要點，必須處理好每一個結點細節，一旦某個地方沒有設計完善，最后的結果可能仍舊達不到要求。 ## 參考資料 > https://segmentfault.com/a/1190000020172463