程式設計中的冪等性 — HTTP冪等性
冪等（idempotent、idempotence）是一個數學與計算機學概念，常見於抽象代數中。
在程式設計中.一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。這些函式不會影響系統狀態，也不用擔心重複執行會對系統造成改變。例如，“getUsername()和setTrue()”函式就是一個冪等函式.更復雜的操作冪等保證是利用唯一交易號(流水號)實現.
——百度百科
什麼是冪等性(Idempotence)？
Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. ——HTTP/1.1規範中冪等性的定義
從定義上看，HTTP方法的冪等性是指一次和多次請求某一個資源應該具有同樣的副作用。說白了就是，同一個請求，傳送一次和傳送N次效果是一樣的！冪等性是分散式系統設計中十分重要的概念，而HTTP的分散式本質也決定了它在HTTP中具有重要地位。下面將以HTTP中的冪等性做例子加以介紹。
簡單示例
假設有一個從賬戶取錢的遠端API（可以是HTTP的，也可以不是），我們暫時用類函式的方式記為：
bool withdraw(account_id, amount)
withdraw的語義是從account_id對應的賬戶中扣除amount數額的錢；如果扣除成功則返回true，賬戶餘額減少amount；如果扣除失敗則返回false，賬戶餘額不變。
值得注意的是：和本地環境相比，我們不能輕易假設分散式環境的可靠性。
所以問題來了，一種典型的情況是withdraw請求已經被伺服器端正確處理，但伺服器端的返回結果由於網路等原因被掉丟了，導致客戶端無法得知處理結果。如果是在網頁上，一些不恰當的設計可能會使使用者認為上一次操作失敗了，然後重新整理頁面，這就導致了withdraw被呼叫兩次，賬戶也被多扣了一次錢。如圖所示：
解決方案一：採用分散式事務，通過引入支援分散式事務的中介軟體來保證withdraw功能的事務性。分散式事務的優點是對於呼叫者很簡單，複雜性都交給了中介軟體來管理。缺點則是一方面架構太重量級，容易被綁在特定的中介軟體上，不利於異構系統的整合；另一方面分散式事務雖然能保證事務的ACID性質，而但卻無法提供效能和可用性的保證。
解決方案二：冪等設計。我們可以通過一些技巧把withdraw變成冪等的，比如：
int create_ticket() bool idempotent_withdraw(ticket_id, account_id, amount)
create_ticket的語義是獲取一個伺服器端生成的唯一的處理號ticket_id，它將用於標識後續的操作。idempotent_withdraw和withdraw的區別在於關聯了一個ticket_id，一個ticket_id表示的操作至多隻會被處理一次，每次呼叫都將返回第一次呼叫時的處理結果。這樣，idempotent_withdraw就符合冪等性了，客戶端就可以放心地多次呼叫。
基於冪等性的解決方案中一個完整的取錢流程被分解成了兩個步驟：1.呼叫create_ticket()獲取ticket_id；2.呼叫idempotent_withdraw(ticket_id, account_id, amount)。雖然create_ticket不是冪等的，但在這種設計下，它對系統狀態的影響可以忽略，加上idempotent_withdraw是冪等的，所以任何一步由於網路等原因失敗或超時，客戶端都可以重試，直到獲得結果。如圖所示：
和分散式事務相比，冪等設計的優勢在於它的輕量級，容易適應異構環境，以及效能和可用性方面。在某些效能要求比較高的應用，冪等設計往往是唯一的選擇。
HTTP的冪等性
本文主要以HTTP GET、DELETE、PUT、POST四種方法為主進行語義和冪等性的介紹。
HTTP GET方法用於獲取資源，不應有副作用，所以是冪等的。比如：GET http://www.bank.com/account/123456，不會改變資源的狀態，不論呼叫一次還是N次都沒有副作用。請注意，這裡強調的是一次和N次具有相同的副作用，而不是每次GET的結果相同。GET http://www.news.com/latest-news這個HTTP請求可能會每次得到不同的結果，但它本身並沒有產生任何副作用，因而是滿足冪等性的。
HTTP DELETE方法用於刪除資源，有副作用，但它應該滿足冪等性。比如：DELETE http://www.forum.com/article/4231，呼叫一次和N次對系統產生的副作用是相同的，即刪掉id為4231的帖子；因此，呼叫者可以多次呼叫或重新整理頁面而不必擔心引起錯誤。
HTTP POST方法用於建立資源，所對應的URI並非建立的資源本身，而是去執行建立動作的操作者，有副作用，不滿足冪等性。比如：POST http://www.forum.com/articles的語義是在http://www.forum.com/articles下建立一篇帖子，HTTP響應中應包含帖子的建立狀態以及帖子的URI。兩次相同的POST請求會在伺服器端建立兩份資源，它們具有不同的URI；所以，POST方法不具備冪等性。
HTTP PUT方法用於建立或更新操作，所對應的URI是要建立或更新的資源本身，有副作用，它應該滿足冪等性。比如：PUT http://www.forum/articles/4231的語義是建立或更新ID為4231的帖子。對同一URI進行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。
對前文示例進行改進
利用Web API的形式實現前面所提到的取款功能。
1、用POST /tickets來實現create_ticket；
2、用PUT /accounts/account_id/ticket_id&amount=xxx來實現idempotent_withdraw。
值得注意的是嚴格來講amount引數不應該作為URI的一部分，真正的URI應該是/accounts/account_id/ticket_id，而amount應該放在請求的body中。這種模式可以應用於很多場合，比如：論壇網站中防止意外的重複發帖。
電商中遇到的問題
如何防範 POST 重複提交
HTTP POST 操作既不是安全的，也不是冪等的（至少在HTTP規範裡沒有保證）。當我們因為反覆重新整理瀏覽器導致多次提交表單，多次發出同樣的POST請求，導致遠端伺服器重複創建出了資源。
所以，對於電商應用來說，第一對應的後端 WebService 一定要做到冪等性，第二伺服器端收到 POST 請求，在操作成功後必須302跳轉到另外一個頁面，這樣即使使用者重新整理頁面，也不會重複提交表單。
把分散式事務分解為具有冪等性的非同步訊息處理
電商的很多業務，考慮更多的是 BASE（即Basically Available、Soft state、和Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability）。即為了滿足高負載的使用者訪問，我們可以容忍短暫的資料不一致。那怎麼做呢？
第一，不做分散式事務，代價太大。
第二，不一定需要實時一致性，只需要保證最終的一致性即可。
第三，“通過狀態機和嚴格的有序操作，來最大限度地降低不一致性”。
第四，最終一致性（Eventually Consistent）通過非同步事件做到。
如果訊息具有操作冪等性，也就是一個訊息被應用多次與應用一次產生的效果是一樣的話，那麼把不需要同步執行的事務交給非同步訊息推送和訂閱者叢集來處理即可。假如訊息處理失敗，那麼就訊息重播，由於冪等性，應用多次也能產生正確的結果。
實際情況下，訊息很難具有冪等性，解決方法是使用另一個表記錄已經被成功應用的訊息，即訊息佇列和訊息應用狀態表一起來解決問題。
總結
上面簡單介紹了冪等性的概念，用冪等設計取代分散式事務的方法，以及HTTP主要方法的語義和冪等性特徵。其實，如果要追根溯源，冪等性是數學中的一個概念，表達的是N次變換與1次變換的結果相同，有興趣的讀者可以從Wikipedia上進一步瞭解。