初次理解是，對於同樣的請求，後台處理過一次之後進入到某乙個狀態後再來一次同樣的請求，後台介面看似不進行處理，但實際是處理了，只是沒有去改變後台或者伺服器的狀態，不會返錯誤,也就是就是乙個操作或者介面，不管你調多少次，每次執行的結果都跟第一次一樣。
乙個http方法是冪等的，指的是同樣的請求被執行一次與連續執行多次的效果是一樣的，伺服器的狀態也是一樣的。換句話說就是，冪等方法不應該具有***（統計用途除外）。在正確實現的條件下，get，head，put和delete 等方法都是冪等的，而 post 方法不是。所有的 safe 方法也都是冪等的。
冪等性只與後端伺服器的實際狀態有關，而每一次請求接收到的狀態碼不一定相同。例如，第一次呼叫delete 方法有可能返回 200，但是後續的請求可能會返回404。delete 的言外之意是，開發者不應該使用delete方法實現具有刪除最後條目功能的 restful api。
伺服器不一定會確保請求方法的冪等性，有些應用可能會錯誤地打破冪等性約束。在對資料準確性要求很高的領域，比如金融、銀行、電商行業就很需要對資料處理介面做到冪等性。
比如，在支付的時候突然碰到網路異常等其他原因導致後台介面已經實施扣款，但是前端返回提示支付失敗，當使用者再進行重試的時候又成功扣了一次款，那問題就大了。在這種場景下這個扣費的介面就需要實現冪等性，第一次扣除成功後伺服器狀態已經發生變化，再進行同樣的扣款請求時就不要再進行再一次的扣款，伺服器的狀態與上一次一樣。
所以對於一些重要的介面或者操作，要求後台保證其冪等性的。因為客戶端可能有重試機制，另外中間人攻擊可能會進行請求的重放，這些都有可能導致介面被多次呼叫。
mvcc: 多版本併發控制，樂觀鎖的一種實現，在資料更新時需要去比較持有資料的版本號，版本號不一致的操作無法成功；設計前期：需要識別需要實現冪等的介面，並與開發確認去重表：利用資料庫表單的特性來實現冪等，常用的乙個思路是在表上構建唯一性索引，保證某一類資料一旦執行完畢，後續同樣的請求再也無法成功寫入。比如部落格上面要想防止乙個人重複點讚，可以設計一張表，將部落格id與使用者id繫結建立唯一索引，每當使用者點讚時就往表中寫入一條資料，這樣重複點讚的資料就無法寫入。
token機制: 這種機制就比較重要了，適用範圍較廣，有多種不同的實現方式。其核心思想是為每一次操作生成乙個唯一性的憑證，也就是token。乙個token在操作的每乙個階段只有一次執行權，一旦執行成功則儲存執行結果。對重複的請求，返回同乙個結果。以電商平台為例子，電商平台上的訂單id就是最適合的token。當使用者下單時，會經歷多個環節，比如生成訂單，減庫存，減優惠券等等。每乙個環節執行時都先檢測一下該訂單id是否已經執行過這一步驟，對未執行的請求，執行操作並快取結果，而對已經執行過的id，則直接返回之前的執行結果，不做任何操作。這樣可以在最大程度上避免操作的重複執行問題，快取起來的執行結果也能用於事務的控制等。
測試：反覆呼叫
測試：反覆呼叫的時候修改看似無關緊要的引數，是否會破壞冪等性
原子性 冪等性
原子性 如果這個操作所處的層 layer 的更高層不能發現其內部實現與結構，那麼這個操作是乙個原子 atomic 操作。原子操作可以是乙個步驟，也可以是多個操作步驟，但是其順序不可以被打亂，也不可以被切割而只執行其中的一部分。將整個操作視作乙個整體是原子性的核心特徵。冪等性 再簡單一點說，在乙個業務...
冪等性學習及介面的冪等性
冪等性學習 一 什麼是冪等性 在這裡需要有以下幾個問題需要注意 2 冪等性不僅僅只是一次或者多次請求的時候對資源沒有 比如根據id對資料庫的查詢操作，此操作對資料庫沒有增刪改，所以多次查詢操作對資料庫結果是沒有任何影響的 3 冪等性還包括了第一次請求資源的時候，對資源產生了 但是在以後多次同樣的請求...
了解冪等性
2 什麼是冪等性 f x f x x被函式f作用一次和作用無限次的結果是一樣的。冪等性應用在軟體系統中，我把它簡單定義為 某個函式或者某個介面使用相同引數呼叫一次或者無限次，其造成的後果是一樣的，在實際應用中一般針對於介面進行冪等性設計。舉個栗子，在系統中，呼叫方a呼叫系統b的介面進行使用者的扣費操...