一、什么是冪等性？什么是冪等操作？ 冪等：是一個(gè)數(shù)學(xué)概念，表示Ｎ次變換和１次變換的結(jié)果相同。 冪等操作：其特點(diǎn)是任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同（不會(huì)改變資源狀態(tài)，對數(shù)據(jù)沒有副作用）。 冪等性：一系列操作都是冪等操作。 冪等接口：冪等接口認(rèn)為，外部調(diào)用者會(huì)存在多次調(diào)用的場景，為了防止重試對數(shù)據(jù)狀態(tài)的改變，需要將接口的設(shè)計(jì)為冪等的 HTTP方法的冪等性是指一次和多次請求某一個(gè)資源應(yīng)該具有同樣的副作用。說白了就是，同一個(gè)請求，發(fā)送一次和發(fā)送N次效果是一樣的！冪等性是分布式系統(tǒng)設(shè)計(jì)中十分重要的概念，而HTTP的分布式本質(zhì)也決定了它在HTTP中具有重要地位。下面將以HTTP中的冪等性做例子加以介紹。
##簡單場景舉例 假設(shè)有一個(gè)從賬戶取錢的遠(yuǎn)程API（可以是HTTP的，也可以不是），我們暫時(shí)用類函數(shù)的方式記為：

1	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è)計(jì)可能會(huì)使用戶認(rèn)為上一次操作失敗了，然后刷新頁面，這就導(dǎo)致了withdraw被調(diào)用兩次，賬戶也被多扣了一次錢。如圖所示：

解決方案一：采用分布式事務(wù)，通過引入支持分布式事務(wù)的中間件來保證withdraw功能的事務(wù)性。分布式事務(wù)的優(yōu)點(diǎn)是對于調(diào)用者很簡單，復(fù)雜性都交給了中間件來管理。 缺點(diǎn)則是一方面架構(gòu)太重量級，容易被綁在特定的中間件上，不利于異構(gòu)系統(tǒng)的集成（個(gè)人理解：中間件容易形成瓶頸）； 另一方面分布式事務(wù)雖然能保證事務(wù)的ACID性質(zhì)，而但卻無法提供性能和可用性的保證（個(gè)人理解：影響系統(tǒng)的并發(fā)性能及工作效率）。
解決方案二：冪等設(shè)計(jì)。我們可以通過一些技巧把withdraw變成冪等的，比如：

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

create_ticket的語義是獲取一個(gè)服務(wù)器端生成的唯一的處理號ticket_id，它將用于標(biāo)識(shí)后續(xù)的操作。idempotent_withdraw和withdraw的區(qū)別在于關(guān)聯(lián)了一個(gè)ticket_id，一個(gè)ticket_id表示的操作至多只會(huì)被處理一次，每次調(diào)用都將返回第一次調(diào)用時(shí)的處理結(jié)果。這樣，idempotent_withdraw就符合冪等性了，客戶端就可以放心地多次調(diào)用。 基于冪等性的解決方案中一個(gè)完整的取錢流程被分解成了兩個(gè)步驟：1.調(diào)用create_ticket()獲取ticket_id；2.調(diào)用idempotent_withdraw(ticket_id, account_id, amount)。雖然create_ticket不是冪等的，但在這種設(shè)計(jì)下，它對系統(tǒng)狀態(tài)的影響可以忽略，加上idempotent_withdraw是冪等的，所以任何一步由于網(wǎng)絡(luò)等原因失敗或超時(shí)，客戶端都可以重試，直到獲得結(jié)果。如圖所示：
和分布式事務(wù)相比，冪等設(shè)計(jì)的優(yōu)勢在于它的輕量級，容易適應(yīng)異構(gòu)環(huán)境，以及性能和可用性方面。在某些性能要求比較高的應(yīng)用，冪等設(shè)計(jì)往往是唯一的選擇。
★★HTTP的冪等性介紹 本文主要以HTTP GET、DELETE、PUT、POST四種方法為主進(jìn)行語義和冪等性的介紹。 HTTP GET方法用于獲取資源，不應(yīng)有副作用，所以是冪等的。比如：GET http://www.bank.com/account/123456，不會(huì)改變資源的狀態(tài)，不論調(diào)用一次還是N次都沒有副作用。請注意，這里強(qiáng)調(diào)的是一次和N次具有相同的副作用，而不是每次GET的結(jié)果相同。GET http://www.news.com/latest-news這個(gè)HTTP請求可能會(huì)每次得到不同的結(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)心引起錯(cuò)誤。 HTTP POST方法用于創(chuàng)建資源，所對應(yīng)的URI并非創(chuàng)建的資源本身，而是去執(zhí)行創(chuàng)建動(dò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請求會(huì)在服務(wù)器端創(chuàng)建兩份資源，它們具有不同的URI；所以，POST方法不具備冪等性。 HTTP PUT方法用于創(chuàng)建或更新操作，所對應(yīng)的URI是要?jiǎng)?chuàng)建或更新的資源本身，有副作用，它應(yīng)該滿足冪等性。比如：PUT http://www.forum/articles/4231的語義是創(chuàng)建或更新ID為4231的帖子。對同一URI進(jìn)行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。
★★對前文示例進(jìn)行改進(jìn)（取款冪等性設(shè)計(jì)） 利用Web API的形式實(shí)現(xiàn)前面所提到的取款功能。 1、用POST /tickets來實(shí)現(xiàn)create_ticket； 2、用PUT /accounts/account_id/ticket_id&amount=xxx來實(shí)現(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)我們因?yàn)榉磸?fù)刷新瀏覽器導(dǎo)致多次提交表單，多次發(fā)出同樣的POST請求，導(dǎo)致遠(yuǎn)端服務(wù)器重復(fù)創(chuàng)建出了資源。 所以，對于電商應(yīng)用來說，第一對應(yīng)的后端 WebService 一定要做到冪等性，第二服務(wù)器端收到 POST 請求，在操作成功后必須302跳轉(zhuǎn)到另外一個(gè)頁面，這樣即使用戶刷新頁面，也不會(huì)重復(fù)提交表單。 ★把分布式事務(wù)分解為具有冪等性的異步消息處理 電商的很多業(yè)務(wù)，考慮更多的是 BASE（即Basically Available、Soft state、和Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability）。即為了滿足高負(fù)載的用戶訪問，我們可以容忍短暫的數(shù)據(jù)不一致。那怎么做呢？ 第一，不做分布式事務(wù)，代價(jià)太大。第二，不一定需要實(shí)時(shí)一致性，只需要保證最終的一致性即可。第三，“通過狀態(tài)機(jī)和嚴(yán)格的有序操作，來最大限度地降低不一致性”。第四，最終一致性（Eventually Consistent）通過異步事件做到。 如果消息具有操作冪等性，也就是一個(gè)消息被應(yīng)用多次與應(yīng)用一次產(chǎn)生的效果是一樣的話，那么把不需要同步執(zhí)行的事務(wù)交給異步消息推送和訂閱者集群來處理即可。假如消息處理失敗，那么就消息重播，由于冪等性，應(yīng)用多次也能產(chǎn)生正確的結(jié)果。 實(shí)際情況下，消息很難具有冪等性，解決方法是使用另一個(gè)表記錄已經(jīng)被成功應(yīng)用的消息，即消息隊(duì)列和消息應(yīng)用狀態(tài)表一起來解決問題。 ★★總結(jié) 上面簡單介紹了冪等性的概念，用冪等設(shè)計(jì)取代分布式事務(wù)的方法，以及HTTP主要方法的語義和冪等性特征。其實(shí)，如果要追根溯源，冪等性是數(shù)學(xué)中的一個(gè)概念，表達(dá)的是N次變換與1次變換的結(jié)果相同，有興趣的讀者可以從Wikipedia上進(jìn)一步了解。

總結(jié)

以上是生活随笔為你收集整理的编程中的幂等性（一）：http幂等性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。