冪等（idempotent、idempotence）是一個數(shù)學(xué)與計算機學(xué)概念，常見于抽象代數(shù)中。

在編程中.一個冪等操作的特點是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。冪等函數(shù)，或冪等方法，是指可以使用相同參數(shù)重復(fù)執(zhí)行，并能獲得相同結(jié)果的函數(shù)。這些函數(shù)不會影響系統(tǒng)狀態(tài)，也不用擔(dān)心重復(fù)執(zhí)行會對系統(tǒng)造成改變。例如，“getUsername()和setTrue()”函數(shù)就是一個冪等函數(shù).更復(fù)雜的操作冪等保證是利用唯一交易號(流水號)實現(xiàn).

——百度百科

什么是冪等性(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規(guī)范中冪等性的定義

從定義上看，HTTP方法的冪等性是指一次和多次請求某一個資源應(yīng)該具有同樣的副作用。說白了就是，同一個請求，發(fā)送一次和發(fā)送N次效果是一樣的！冪等性是分布式系統(tǒng)設(shè)計中十分重要的概念，而HTTP的分布式本質(zhì)也決定了它在HTTP中具有重要地位。下面將以HTTP中的冪等性做例子加以介紹。

簡單示例

假設(shè)有一個從賬戶取錢的遠(yuǎn)程API（可以是HTTP的，也可以不是），我們暫時用類函數(shù)的方式記為：

bool withdraw(account_id, amount)

withdraw的語義是從account_id對應(yīng)的賬戶中扣除amount數(shù)額的錢；如果扣除成功則返回true，賬戶余額減少amount；如果扣除失敗則返回false，賬戶余額不變。

值得注意的是：和本地環(huán)境相比，我們不能輕易假設(shè)分布式環(huán)境的可靠性。

所以問題來了，一種典型的情況是withdraw請求已經(jīng)被服務(wù)器端正確處理，但服務(wù)器端的返回結(jié)果由于網(wǎng)絡(luò)等原因被掉丟了，導(dǎo)致客戶端無法得知處理結(jié)果。如果是在網(wǎng)頁上，一些不恰當(dāng)?shù)脑O(shè)計可能會使用戶認(rèn)為上一次操作失敗了，然后刷新頁面，這就導(dǎo)致了withdraw被調(diào)用兩次，賬戶也被多扣了一次錢。如圖所示：

解決方案一：采用分布式事務(wù)，通過引入支持分布式事務(wù)的中間件來保證withdraw功能的事務(wù)性。分布式事務(wù)的優(yōu)點是對于調(diào)用者很簡單，復(fù)雜性都交給了中間件來管理。缺點則是一方面架構(gòu)太重量級，容易被綁在特定的中間件上，不利于異構(gòu)系統(tǒng)的集成；另一方面分布式事務(wù)雖然能保證事務(wù)的ACID性質(zhì)，而但卻無法提供性能和可用性的保證。

解決方案二：冪等設(shè)計。我們可以通過一些技巧把withdraw變成冪等的，比如：

int create_ticket() 
bool idempotent_withdraw(ticket_id, account_id, amount)

create_ticket的語義是獲取一個服務(wù)器端生成的唯一的處理號ticket_id，它將用于標(biāo)識后續(xù)的操作。idempotent_withdraw和withdraw的區(qū)別在于關(guān)聯(lián)了一個ticket_id，一個ticket_id表示的操作至多只會被處理一次，每次調(diào)用都將返回第一次調(diào)用時的處理結(jié)果。這樣，idempotent_withdraw就符合冪等性了，客戶端就可以放心地多次調(diào)用。

基于冪等性的解決方案中一個完整的取錢流程被分解成了兩個步驟：1.調(diào)用create_ticket()獲取ticket_id；2.調(diào)用idempotent_withdraw(ticket_id, account_id, amount)。雖然create_ticket不是冪等的，但在這種設(shè)計下，它對系統(tǒng)狀態(tài)的影響可以忽略，加上idempotent_withdraw是冪等的，所以任何一步由于網(wǎng)絡(luò)等原因失敗或超時，客戶端都可以重試，直到獲得結(jié)果。如圖所示：

和分布式事務(wù)相比，冪等設(shè)計的優(yōu)勢在于它的輕量級，容易適應(yīng)異構(gòu)環(huán)境，以及性能和可用性方面。在某些性能要求比較高的應(yīng)用，冪等設(shè)計往往是唯一的選擇。

HTTP的冪等性

本文主要以HTTP GET、DELETE、PUT、POST四種方法為主進(jìn)行語義和冪等性的介紹。

HTTP GET方法用于獲取資源，不應(yīng)有副作用，所以是冪等的。比如：GET http://www.bank.com/account/123456，不會改變資源的狀態(tài)，不論調(diào)用一次還是N次都沒有副作用。請注意，這里強調(diào)的是一次和N次具有相同的副作用，而不是每次GET的結(jié)果相同。GET http://www.news.com/latest-news這個HTTP請求可能會每次得到不同的結(jié)果，但它本身并沒有產(chǎn)生任何副作用，因而是滿足冪等性的。

HTTP DELETE方法用于刪除資源，有副作用，但它應(yīng)該滿足冪等性。比如：DELETE http://www.forum.com/article/4231，調(diào)用一次和N次對系統(tǒng)產(chǎn)生的副作用是相同的，即刪掉id為4231的帖子；因此，調(diào)用者可以多次調(diào)用或刷新頁面而不必?fù)?dān)心引起錯誤。

HTTP POST方法用于創(chuàng)建資源，所對應(yīng)的URI并非創(chuàng)建的資源本身，而是去執(zhí)行創(chuàng)建動作的操作者，有副作用，不滿足冪等性。比如：POST http://www.forum.com/articles的語義是在http://www.forum.com/articles下創(chuàng)建一篇帖子，HTTP響應(yīng)中應(yīng)包含帖子的創(chuàng)建狀態(tài)以及帖子的URI。兩次相同的POST請求會在服務(wù)器端創(chuàng)建兩份資源，它們具有不同的URI；所以，POST方法不具備冪等性。

HTTP PUT方法用于創(chuàng)建或更新操作，所對應(yīng)的URI是要創(chuàng)建或更新的資源本身，有副作用，它應(yīng)該滿足冪等性。比如：PUT http://www.forum/articles/4231的語義是創(chuàng)建或更新ID為4231的帖子。對同一URI進(jìn)行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。

對前文示例進(jìn)行改進(jìn)

利用Web API的形式實現(xiàn)前面所提到的取款功能。

1、用POST /tickets來實現(xiàn)create_ticket；

2、用PUT /accounts/account_id/ticket_id&amount=xxx來實現(xiàn)idempotent_withdraw。

值得注意的是嚴(yán)格來講amount參數(shù)不應(yīng)該作為URI的一部分，真正的URI應(yīng)該是/accounts/account_id/ticket_id，而amount應(yīng)該放在請求的body中。這種模式可以應(yīng)用于很多場合，比如：論壇網(wǎng)站中防止意外的重復(fù)發(fā)帖。

電商中遇到的問題

如何防范 POST 重復(fù)提交

HTTP POST 操作既不是安全的，也不是冪等的（至少在HTTP規(guī)范里沒有保證）。當(dāng)我們因為反復(fù)刷新瀏覽器導(dǎo)致多次提交表單，多次發(fā)出同樣的POST請求，導(dǎo)致遠(yuǎn)端服務(wù)器重復(fù)創(chuàng)建出了資源。

所以，對于電商應(yīng)用來說，第一對應(yīng)的后端 WebService 一定要做到冪等性，第二服務(wù)器端收到 POST 請求，在操作成功后必須302跳轉(zhuǎn)到另外一個頁面，這樣即使用戶刷新頁面，也不會重復(fù)提交表單。

把分布式事務(wù)分解為具有冪等性的異步消息處理

電商的很多業(yè)務(wù)，考慮更多的是 BASE（即Basically Available、Soft state、和Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability）。即為了滿足高負(fù)載的用戶訪問，我們可以容忍短暫的數(shù)據(jù)不一致。那怎么做呢？

第一，不做分布式事務(wù)，代價太大。
第二，不一定需要實時一致性，只需要保證最終的一致性即可。
第三，“通過狀態(tài)機和嚴(yán)格的有序操作，來最大限度地降低不一致性”。
第四，最終一致性（Eventually Consistent）通過異步事件做到。

如果消息具有操作冪等性，也就是一個消息被應(yīng)用多次與應(yīng)用一次產(chǎn)生的效果是一樣的話，那么把不需要同步執(zhí)行的事務(wù)交給異步消息推送和訂閱者集群來處理即可。假如消息處理失敗，那么就消息重播，由于冪等性，應(yīng)用多次也能產(chǎn)生正確的結(jié)果。

實際情況下，消息很難具有冪等性，解決方法是使用另一個表記錄已經(jīng)被成功應(yīng)用的消息，即消息隊列和消息應(yīng)用狀態(tài)表一起來解決問題。

總結(jié)

上面簡單介紹了冪等性的概念，用冪等設(shè)計取代分布式事務(wù)的方法，以及HTTP主要方法的語義和冪等性特征。其實，如果要追根溯源，冪等性是數(shù)學(xué)中的一個概念，表達(dá)的是N次變換與1次變換的結(jié)果相同，有興趣的讀者可以從Wikipedia上進(jìn)一步了解。

轉(zhuǎn)自：http://www.i3geek.com/archives/841