分布式架構(gòu)中的冪等性

一. 斷言：冪等性的數(shù)學(xué)表達(dá)：f(f(x) = f(x)。冪等性是系統(tǒng)接口對外的一種承諾。冪等性指的是，使用相同參數(shù)對同一資源重復(fù)調(diào)用某個接口的結(jié)果與調(diào)用一次的結(jié)果相同。冪等性的一個實現(xiàn)是，使你的接口必須返回 0（成功），即使這時資源或動作已經(jīng)停止并且無工作要完成。二. 電商常見問題： 2.1. 如何防范 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ù)提交表單。2.2. 集群環(huán)境下的定時任務(wù)冪等性分布式環(huán)境下，定時任務(wù)或異步處理如何保持冪等性？三. 把分布式事務(wù)分解為具有冪等性的異步消息處理：電商的很多業(yè)務(wù)，考慮更多的是 BASE（即Basically Available、Soft state、和Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability）。即為了滿足高負(fù)載的用戶訪問，我們可以容忍短暫的數(shù)據(jù)不一致。那怎么做呢？第一，不做分布式事務(wù)，代價太大。第二，不一定需要實時一致性，只需要保證最終的一致性即可。第三，“通過狀態(tài)機(jī)和嚴(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)表一起來解決問題。參考資源：1）weidagang2046，博客園，理解HTTP冪等性；2）相關(guān)設(shè)計模式“Synchronized Token（簡而言之，就是客戶端的每一次 Request 里，必須攜帶一個服務(wù)器端給出的 Hash Code 作為 Token，這個 Token 只能用一次，不能重復(fù)使用） ”和“冪等接收器，Idempotent Receiver ”；3）針對 POST ，請參考HTTPLR（由Bill de hra提出）、Mark Nottingham的POE（POST Once Exactly）和Paul Prescod的HTTP中的可靠傳遞。（另一個值得一提的是Yaron Goland的SOA-Rity）；4）淘寶核心系統(tǒng)團(tuán)隊博客，2010，用消息隊列和消息應(yīng)用狀態(tài)表來消除分布式事務(wù) 電商課題：RBAC權(quán)限控制 電商課題VI：分布式Session 電商課題：cookie防篡改 電商課題V：分布式鎖 電商課題I：Throttle Limits for calls/requests in a clustered environmentTodd.log - a place to keep my thoughts on programming理解HTTP冪等性基于HTTP協(xié)議的Web API是時下最為流行的一種分布式服務(wù)提供方式。無論是在大型互聯(lián)網(wǎng)應(yīng)用還是企業(yè)級架構(gòu)中，我們都見到了越來越多的SOA或RESTful的Web API。為什么Web API如此流行呢？我認(rèn)為很大程度上應(yīng)歸功于簡單有效的HTTP協(xié)議。HTTP協(xié)議是一種分布式的面向資源的網(wǎng)絡(luò)應(yīng)用層協(xié)議，無論是服務(wù)器端提供Web服 務(wù)，還是客戶端消費Web服務(wù)都非常簡單。再加上瀏覽器、Javascript、AJAX、JSON以及HTML5等技術(shù)和工具的發(fā)展，互聯(lián)網(wǎng)應(yīng)用架構(gòu)設(shè) 計表現(xiàn)出了從傳統(tǒng)的PHP、JSP、ASP.NET等服務(wù)器端動態(tài)網(wǎng)頁向Web API + RIA（富互聯(lián)網(wǎng)應(yīng)用）過渡的趨勢。Web API專注于提供業(yè)務(wù)服務(wù)，RIA專注于用戶界面和交互設(shè)計，從此兩個領(lǐng)域的分工更加明晰。在這種趨勢下，Web API設(shè)計將成為服務(wù)器端程序員的必修課。然而，正如簡單的Java語言并不意味著高質(zhì)量的Java程序，簡單的HTTP協(xié)議也不意味著高質(zhì)量的Web API。要想設(shè)計出高質(zhì)量的Web API，還需要深入理解分布式系統(tǒng)及HTTP協(xié)議的特性。冪等性定義本文所要探討的正是HTTP協(xié)議涉及到的一種重要性質(zhì)：冪等性(Idempotence)。在HTTP/1.1規(guī)范中冪等性的定義是：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方法的冪等性是指一次和多次請求某一個資源應(yīng)該具有同樣的副作用。冪等性屬于語義范疇，正如編譯器只能幫助檢查語法錯誤一 樣，HTTP規(guī)范也沒有辦法通過消息格式等語法手段來定義它，這可能是它不太受到重視的原因之一。但實際上，冪等性是分布式系統(tǒng)設(shè)計中十分重要的概念，而 HTTP的分布式本質(zhì)也決定了它在HTTP中具有重要地位。分布式事務(wù) vs 冪等設(shè)計為什么需要冪等性呢？我們先從一個例子說起，假設(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)用兩次，賬戶也被多扣了一次錢。如圖1所示：圖1這個問題的解決方案一是采用分布式事務(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é)果。如圖2所示：圖2和分布式事務(wù)相比，冪等設(shè)計的優(yōu)勢在于它的輕量級，容易適應(yīng)異構(gòu)環(huán)境，以及性能和可用性方面。在某些性能要求比較高的應(yīng)用，冪等設(shè)計往往是唯一的選擇。HTTP的冪等性HTTP協(xié)議本身是一種面向資源的應(yīng)用層協(xié)議，但對HTTP協(xié)議的使用實際上存在著兩種不同的方式：一種是RESTful的，它把HTTP當(dāng)成應(yīng)用 層協(xié)議，比較忠實地遵守了HTTP協(xié)議的各種規(guī)定；另一種是SOA的，它并沒有完全把HTTP當(dāng)成應(yīng)用層協(xié)議，而是把HTTP協(xié)議作為了傳輸層協(xié)議，然后 在HTTP之上建立了自己的應(yīng)用層協(xié)議。本文所討論的HTTP冪等性主要針對RESTful風(fēng)格的，不過正如上一節(jié)所看到的那樣，冪等性并不屬于特定的協(xié) 議，它是分布式系統(tǒng)的一種特性；所以，不論是SOA還是RESTful的Web API設(shè)計都應(yīng)該考慮冪等性。下面將介紹HTTP GET、DELETE、PUT、POST四種主要方法的語義和冪等性。HTTP GET方法用于獲取資源，不應(yīng)有副作用，所以是冪等的。比如：GET /account/123456，不會改變資源的狀態(tài)，不論調(diào)用一次還是N次都沒有副作用。請注意，這里強(qiáng)調(diào)的是 一次和N次具有相同的副作用，而不是每次GET的結(jié)果相同。GET /latest-news這個HTTP請求可能會每次得到不同的結(jié)果，但它本身并沒有產(chǎn)生任何副作用，因而是滿足 冪等性的。HTTP DELETE方法用于刪除資源，有副作用，但它應(yīng)該滿足冪等性。比如：DELETE /article/4231，調(diào)用一次和N次對系統(tǒng)產(chǎn)生的副作用是相同的，即刪掉id為4231的帖子；因此， 調(diào)用者可以多次調(diào)用或刷新頁面而不必?fù)?dān)心引起錯誤。比較容易混淆的是HTTP POST和PUT。POST和PUT的區(qū)別容易被簡單地誤認(rèn)為“POST表示創(chuàng)建資源，PUT表示更新資源”；而實際上，二者均可用于創(chuàng)建資源，更為本質(zhì)的差別是在冪等性方面。在HTTP規(guī)范中對POST和PUT是這樣定義的：The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line . If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.POST所對應(yīng)的URI并非創(chuàng)建的資源本身，而是資源的接收者。比如：POST /articles的語義是在/articles下創(chuàng)建一篇帖 子，HTTP響應(yīng)中應(yīng)包含帖子的創(chuàng)建狀態(tài)以及帖子的URI。兩次相同的POST請求會在服務(wù)器端創(chuàng)建兩份資源，它們具有不同的URI；所以，POST方法 不具備冪等性。而PUT所對應(yīng)的URI是要創(chuàng)建或更新的資源本身。比如：PUT http:/www.forum/articles/4231的語義是創(chuàng)建或更新ID為4231的帖子。對同一URI進(jìn)行多次PUT的副作用和一次 PUT是相同的；因此，PUT方法具有冪等性。在介紹了幾種操作的語義和冪等性之后，我們來看看如何通過Web API的形式實現(xiàn)前面所提到的取款功能。很簡單，用POST /tickets來實現(xiàn)create_ticket；用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)