什麼是冪等性，就是你操作無數波操作和你操作一波效果一毛一樣的
http冪等方法，是指無論呼叫多少次都不會有不同結果的 http 方法。不管你呼叫一次，還是呼叫一百次，一千次，結果都是相同的。
http get方法，用於獲取資源，不管呼叫多少次介面，它都是顯示的資源,而並沒有改變，所以是冪等的。
http post方法是乙個非冪等方法，因為呼叫多次，都將產生新的資源。
因為它會對資源本身產生影響，每次呼叫都會有新的資源產生，因此不滿足冪等性。
下面介紹一些解決非冪等性的方法
1）利用樂觀鎖
通過版本號去控制,資料庫這種建立version欄位,如果要更改時先查詢一下這個欄位的版本,插入時如果我們查詢到的版本號<=資料庫中的版本號則失敗,需要重新提交
2）悲觀鎖
操作時直接鎖表(或者鎖行?),不能別人在進行操作
悲觀鎖和樂觀鎖的區別
1.響應速度：如果需要非常高的響應速度，建議採用樂觀鎖方案，成功就執行，不成功就失敗，不需要等待其他併發去釋放鎖
2.衝突頻率：如果衝突頻率非常高，建議採用悲觀鎖，保證成功率，如果衝突頻率大，樂觀鎖會需要多次重試才能成功，代價比較大
3.重試代價：如果重試代價大，建議採用悲觀鎖
3)redis分布式鎖
支付完刪除值，所以可以防止多次提交
4）token令牌的問題
支付前拿到乙個token，然後支付的時候帶上這個token，驗證真實性然後如果redis上有這個token說明還沒支付，否則就已經支付完成(第三方平台大部分使用的此策略)
原子性 冪等性
原子性 如果這個操作所處的層 layer 的更高層不能發現其內部實現與結構，那麼這個操作是乙個原子 atomic 操作。原子操作可以是乙個步驟，也可以是多個操作步驟，但是其順序不可以被打亂，也不可以被切割而只執行其中的一部分。將整個操作視作乙個整體是原子性的核心特徵。冪等性 再簡單一點說，在乙個業務...
關於介面冪等性的設計
關於支付相關，訂單相關以及一些涉及費用的操作在業務上都是要求介面具有冪等性的。否則在高併發的場景下，同一筆交易請求多次，則會造成損失，這是不可忽視的錯誤。例如一筆訂單，因為網路或者操作的原因，造成同時發起了兩次申請。一般的介面設計中，對於重 起的交易都是先查詢是否存在這筆訂單，如果不存在，則繼續進行...
冪等性學習及介面的冪等性
冪等性學習 一 什麼是冪等性 在這裡需要有以下幾個問題需要注意 2 冪等性不僅僅只是一次或者多次請求的時候對資源沒有 比如根據id對資料庫的查詢操作，此操作對資料庫沒有增刪改，所以多次查詢操作對資料庫結果是沒有任何影響的 3 冪等性還包括了第一次請求資源的時候，對資源產生了 但是在以後多次同樣的請求...