@鄭昀匯總
關鍵詞：
idempotency，BASE，
一. 斷言：
冪等性的數學表達：f(f(x)) = f(x)。
冪等性是系統接口對外的一種承諾。
冪等性指的是，使用相同參數對同一資源重復調用某個接口的結果與調用一次的結果相同。
冪等性的一個實現是，使你的接口必須返回 0（成功），即使這時資源或動作已經停止並且無工作要完成。
二. 電商常見問題：
2.1. 如何防范 POST 重復提交
HTTP POST 操作既不是安全的，也不是冪等的（至少在HTTP規范里沒有保證）。
當我們因為反復刷新瀏覽器導致多次提交表單，多次發出同樣的POST請求，導致遠端服務器重復創建出了資源。
所以，對於電商應用來說，第一對應的后端 WebService 一定要做到冪等性，第二服務器端收到 POST 請求，
在操作成功后必須302跳轉到另外一個頁面，這樣即使用戶刷新頁面，也不會重復提交表單。
2.2. 集群環境下的定時任務冪等性
分布式環境下，定時任務或異步處理如何保持冪等性？
三. 把分布式事務分解為具有冪等性的異步消息處理：
電商的很多業務，考慮更多的是 BASE（即
Basically Available、
Soft state、和
Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability）。即為了滿足高負載的用戶訪問，我們可以容忍短暫的數據不一致。
那怎么做呢？
第一，不做分布式事務，代價太大。
第二，不一定需要實時一致性，只需要保證最終的一致性即可。
第三，“通過狀態機和嚴格的有序操作，來最大限度地降低不一致性”。
第四，最終一致性（Eventually Consistent）通過異步事件做到。
如果消息具有操作冪等性，也就是一個消息被應用多次與應用一次產生的效果是一樣的話，那么
把不需要同步執行的事務交給異步消息推送和訂閱者集群來處理即可。假如消息處理失敗，那么就消息重播，由於冪等性，應用多次也能產生正確的結果。
實際情況下，消息很難具有冪等性，解決方法是使用另一個表記錄已經被成功應用的消息，即消息隊列和消息應用狀態表一起來解決問題。
參考資源：
1）weidagang2046，博客園，
理解HTTP冪等性；
2）相關設計模式“Synchronized Token（簡而言之，就是客戶端的每一次 Request 里，必須攜帶一個服務器端給出的 Hash Code 作為 Token，這個 Token 只能用一次，不能重復使用） ”和“冪等接收器，Idempotent Receiver ”；
3）針對 POST ，請參考
HTTPLR（由Bill de hÓra提出）、
Mark Nottingham的POE（POST Once Exactly）和Paul Prescod的
HTTP中的可靠傳遞。（另一個值得一提的是Yaron Goland的
SOA-Rity）；
4）淘寶核心系統團隊博客，2010，
用消息隊列和消息應用狀態表來消除分布式事務