冪等這個詞原自數學，某一元運算為冪等時，其作用在任一元素兩次後會和其作用一次的結果相同。在程式設計中，乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。第一次請求的時候對資源產生了***，但是以後的多次請求都不會再對資源產生***。這裡的***是不會對結果產生破壞或者產生不可預料的結果。
比如，某服務記錄關鍵資料 x，當前值為 100。a 請求需要將 x 增加 200；同時，b 請求需要將 x 減去 100。在理想的情況下，a 先讀取到 x=100，然後 x 增加 200，最後 x=300。b 請求接著從讀取 x=300，減去 100，最後 x=200。 然而在真實情況下，如果不做任何處理，則可能會出現：a 和 b 同時讀取到 x=100；假如 a 比 b 先執行完，那麼最後 x=0，如果 b 比 a 先執行完，那麼最後 x=300。不管是那種情況發生了，都產生了***或者說是產生了不可預料的結果，並且是不可以接受的異常。這種情況就是我們提供的方法或者介面不滿足冪等性，導致的不可預料的結果。
1.建立唯一索引，防止新增髒資料
這個可以限制重複插入資料，當重複時，資料庫會拋異常，保證不會出現髒資料。但體驗不好，並且實用場景有限制。
2.利用 token 機制，防止頁面重複提交
核心思想是為每一次操作生成乙個唯一性的憑證，也就是token。乙個token在操作的每乙個階段只有一次執行權，一旦執行成功則儲存執行結果。對重複的請求，返回同乙個結果。
3.狀態機冪等
在有狀態的資料中可以使用，如果狀態機已經處於下乙個狀態，這時候來了乙個上乙個狀態的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態機的冪等。如果狀態是順序的，不可逆，那麼就不會出現 aba 問題，否則會出現 aba問題。
4.select + insert
這種情況在沒有併發的系統中可以解決冪等問題，在單jvm有併發的時候可以加鎖來保證冪等性，在分布式環境它是沒發保證冪等的，這時候需要用到分布式鎖來保證。
5.分布式鎖
在進入方法時，先去獲取鎖，假如獲取到鎖，就繼續後面的流程。假如沒有獲取到鎖，就等待鎖的釋放直到獲取到鎖。當執行完方法時，釋放鎖。當然，鎖要設個超時時間，防止意外沒有釋放到鎖。它用來解決分布式系統的冪等性，常用的實現方案是 redis 和 zookeeper 等工具。
6.對外提供冪等的介面
通過 source**+seq序列號來判斷請求是否重複， 在併發時只能處理乙個請求。其它相同併發請求要麼返回請求重複，要麼等待前面請求執行完成在執行。
1.增加了額外控制冪等的業務邏輯，複雜化了業務功能。
2.把並行執行的功能改為序列執行，降低了執行效率。
最後，冪等性雖然複雜化了業務功能和降低了執行效率，但為了保證系統的正確性，是必要的。就上面更新 x 的例子，在單台伺服器上，給那段**加上鎖，並給 x 設為 volatile，就保證來資料的正確性了。在分布式環境下並且 x 是從資料庫或者檔案裡查詢出來的，用上面加鎖的方式實現就不能保證資料的正確性了，這時候就需要用到分布式鎖了。所以，保證方法或介面的冪等性是非常有必要的，因為資料是不能出現任何問題的。
冪等性的實現
1.生成key的方式 記得保證redis生成的key和刪除的key是成功的 看返回值 1 允許表單跳轉 這種情況比較容易，比如在列表中新增一條記錄，可以在列表頁面生成乙個key，放到redis中，同時在新增頁面時帶著這個key。等到提交時，把key也提交，後台根據key與redis中進行比較，有的話...
冪等性的實現
1.生成key的方式 記得保證redis生成的key和刪除的key是成功的 看返回值 1 允許表單跳轉 這種情況比較容易，比如在列表中新增一條記錄，可以在列表頁面生成乙個key，放到redis中，同時在新增頁面時帶著這個key。等到提交時，把key也提交，後台根據key與redis中進行比較，有的話...
冪等性學習及介面的冪等性
冪等性學習 一 什麼是冪等性 在這裡需要有以下幾個問題需要注意 2 冪等性不僅僅只是一次或者多次請求的時候對資源沒有 比如根據id對資料庫的查詢操作，此操作對資料庫沒有增刪改，所以多次查詢操作對資料庫結果是沒有任何影響的 3 冪等性還包括了第一次請求資源的時候，對資源產生了 但是在以後多次同樣的請求...