在Java web項目開發中，經常會聽到在做訂單系統中生成訂單的時候，要做冪等性控制和並發控制，特對此部分內容作出總結，在高並發場景下，代碼層面需要實現並發控制；但是冪等性，其實更多的是系統的接口對外的一種承諾，承諾一次請求和多次請求會返回同樣的數據。關於冪等性將分別從高等代數中的冪等性、HTTP中的冪等性和訂單生成系統中的冪等性闡述；並發性控制則提供了分布式鎖等方式來對並發場景進行代碼實現。
一、冪等性 idempotence ['aɪdəmpoʊtəns]
1.高等代數中關於冪等idempotence概念解釋：
單目運算, x為某集合內的任意數, 如果滿足f(x)=f(f(x)), 那么我們稱f運算為具有冪等性(idempotent)。比如在實數集中,絕對值運算就是一個例子: abs(a)=abs(abs(a))。
雙目運算，x為某集合內的任意數, f為運算子如果滿足f(x,x)=x, f運算的前提是兩個參數都同為x, 那么我們也稱f運算為具有冪等性。比如在實數集中,求兩個數的最大值的函數: max(x,x) = x, 還有布爾代數中,邏輯運算 "與", "或" 也都是冪等運算, 因為他們符合AND(0,0) = 0, AND(1,1) = 1, OR(0,0) = 0, OR(1,1) = 1。
在將冪等性應用到軟件開發中,需要一些更深的理解，我的理解如下:數學處理的是運算和數值, 程序開發中往往處理的是對象和函數. 但是我們不能簡單地理解為數學冪等中的運算就是函數,而數值就是對象。如Person對象有兩個屬性weight和age,但是所有的function只能對其中一個屬性操作。所以從這個層面我們可以理解為: 函數只對該函數所操作的對象某個屬性具有冪等性, 而不是說對整個對象有運算冪等性。
Person { private int weight; private int age; //是冪等函數 public void setAge(int v){ this.age = v; } //不是冪等函數 public void increaseAge(){ this.age++; } //是冪等函數 public void setWeight(int v){ this.weight=v+10;//故意加10斤!! } }
還有一點必須要澄清的是: 冪等性所表達的概念關注的是數學層面的運算和數值, 並沒有提及到數值的安全性問題.如上面的Person的setAge函數, 有兩種case不是冪等性所關心的, 但程序開發卻又必須要關心的:
- 兩個線程同時調用
- 因為age從業務上講不可能遞減, 如果前一次調用設置是30歲, 后一次調用變成了10歲或是更離譜的 -1 歲
冪等性是系統的接口對外一種承諾(而不是實現), 承諾只要調用接口成功, 外部多次調用對系統的影響是一致的。聲明為冪等的接口會認為外部調用失敗是常態, 並且失敗之后必然會有重試。所以RESTful設計中將冪等性和安全性作為兩個不同的指標來衡量POST,PUT,GET,DELETE操作的。因此，post不是冪等性的，put get delete都是冪等性的，也即在生成訂單的post請求中，我們要做冪等性的控制。如下圖，一個ajax請求是一次post請求的示例，如果這個post請求被調用多次，它會向表插入多條記錄，很顯然post請求並不是冪等性的，所以冪等性的控制交由我們程序中來控制。
2.HTTP協議中的冪等性
項目中中的SOA和restful API接口的流行，都需要應用層HTTP協議的支持，目前的項目結構：Web API + RIA（Rich Internet Applications富互聯網應用），Web API專注於提供業務服務，RIA專注於用戶界面和交互設計，從此兩個領域的分工更加明晰。正如簡單的Java語言並不意味着高質量的Java程序，簡單的HTTP協議也不意味着高質量的Web API。要想設計出高質量的Web API，還需要深入理解分布式系統及HTTP協議的特性。在HTTP1.1規范中定義冪等性。
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方法的冪等性是指一次和多次請求某一個資源應該具有同樣的作用。冪等性是分布式系統設計中十分重要的概念，而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的語義是獲取一個服務器端生成的唯一的處理號token，它將用於標識后續的操作。idempotent_withdraw和withdraw的區別在於關聯了一個token，一個token表示的操作至多只會被處理一次，每次調用都將返回第一次調用時的處理結果。這樣，idempotent_withdraw就符合冪等性了，客戶端就可以放心地多次調用。也就是說，多次點擊提交的時候，附帶提交的還有服務端生成的token，由於多次提交帶的是同一個token，所以服務端對於同一個token的post訂單，至多只會處理一次，所以間接的實現了冪等性的控制。
基於冪等性的解決方案中一個完整的取錢流程被分解成了兩個步驟：1.調用create_ticket()獲取token；2.調用idempotent_withdraw(token, account_id, amount)。雖然create_ticket不是冪等的，但在這種設計下，它對系統狀態的影響可以忽略，加上idempotent_withdraw是冪等的，所以任何一步由於網絡等原因失敗或超時，客戶端都可以重試，直到獲得結果。如圖2所示：
和分布式事務相比，冪等設計的優勢在於它的輕量級，容易適應異構環境，以及性能和可用性方面。在某些性能要求比較高的應用中，冪等設計往往是唯一的選擇。
- 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和PUT。POST和PUT的區別容易被簡單地誤認為“POST表示創建資源，PUT表示更新資源”；而實際上，二者均可用於創建資源，更為本質的差別是在冪等性方面。在HTTP規范中對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所對應的URI並非創建的資源本身，而是資源的接收者。比如：POST http://www.forum.com/articles的語義是在http://www.forum.com/articles下創建一篇帖子，HTTP響應中應包含帖子的創建狀態以及帖子的URI。兩次相同的POST請求會在服務器端創建兩份資源，它們具有不同的URI；所以，POST方法不具備冪等性。而PUT所對應的URI是要創建或更新的資源本身。比如：PUT http://www.forum/articles/4231的語義是創建或更新ID為4231的帖子。對同一URI進行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。論壇網站防止重復發帖和訂單生成都用到token方式的冪等性控制。
3.總結
在電商系統中，常見問題：如何防范post請求的重復提交？HTTP POST 操作既不是安全的，也不是冪等的。當我們因為反復刷新瀏覽器導致多次提交表單，多次發出同樣的POST請求，導致遠端服務器重復創建出了資源。所以，對於電商應用來說，第一對應的后端 WebService 一定要做到冪等性，第二服務器端收到 POST 請求，在操作成功后必須跳轉到另外一個頁面，這樣即使用戶刷新頁面，也不會重復提交表單。
二、高並發
1.分布式鎖的定義
分布式鎖是控制分布式系統之間同步訪問共享資源的一種方式。在分布式系統中，常常需要協調他們的動作。如果不同的系統或是同一個系統的不同主機之間共享了一個或一組資源，那么訪問這些資源的時候，往往需要互斥來防止彼此干擾來保證一致性，在這種情況下，便需要使用到分布式鎖。分布式鎖是一個在很多環境中非常有用的原語，它是不同的系統或是同一個系統的不同主機之間互斥操作共享資源的有效方法。如在電商系統中，需要保證整個分布式系統內，對一個重要事物（訂單，賬戶等）的有效操作線程 ，同一時間內有且只有一個。比如交易中心有N台服務器，訂單中心有M台服務器，如何保證一個訂單的同一筆支付處理，一個賬戶的同一筆充值操作是原子性的。
常見的實現分布式鎖的服務有：memcache zookeeper redis chubby hazelcast。
2.分布式鎖實現
分布式鎖在分布式應用當中是要經常用到的，主要是解決分布式資源訪問沖突的問題。傳統的鎖ReentrantLock在去實現的時候是有問題的，ReentrantLock的lock和unlock要求必須是在同一線程進行，而分布式應用中，lock和unlock是兩次不相關的請求，因此肯定不是同一線程，因此導致無法使用ReentrantLock。
附：
1、什么是restful風格的API接口？
http://www.ruanyifeng.com/blog/2014/05/restful_api.html
http://www.cnblogs.com/zhengyun_ustc/archive/2012/11/17/topic2.html
http://www.cnblogs.com/j2eetop/p/4612437.html
http://www.cnblogs.com/weidagang2046/p/exception-handling-principles.html
http://www.cnblogs.com/orange1438/p/4637776.html