java冪等,java冪等問題

本文目錄一覽：

• 1、JAVA中Get和Post請求的區別收集整理
• 2、一起討論下，消息冪等（去重）通用解決方案
• 3、如何判斷請求的冪等性 java
• 4、java程序領取優惠卷,高並發下怎麼避免領取量超過預發量

JAVA中Get和Post請求的區別收集整理

一 原理區別

一般在瀏覽器中輸入網址訪問資源都是通過GET方式；在FORM提交中，可以通過Method指定提交方式為GET或者POST，默認為GET提交

Http定義了與服務器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE

URL全稱是資源描述符，我們可以這樣認為：一個URL地址，它用於描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應着對這個資源的查 ，改 ，增 ，刪 4個操作。到這裡，大家應該有個大概的了解了，GET一般用於獲取/查詢 資源信息，而POST一般用於更新 資源信息(個人認為這是GET和POST的本質區別，也是協議設計者的本意，其它區別都是具體表現形式的差異 )。

根據HTTP規範，GET用於信息獲取，而且應該是安全的和冪等的 。

1.所謂安全的意味着該操作用於獲取信息而非修改信息。換句話說，GET請求一般不應產生副作用。就是說，它僅僅是獲取資源信息，就像數據庫查詢一樣，不會修改，增加數據，不會影響資源的狀態。

* 注意：這裡安全的含義僅僅是指是非修改信息。

2.冪等的意味着對同一URL的多個請求應該返回同樣的結果。這裡我再解釋一下冪等 這個概念：

冪等 （idempotent、idempotence）是一個數學或計算機學概念，常見於抽象代數中。

冪等有以下幾種定義：

對於單目運算，如果一個運算對於在範圍內的所有的一個數多次進行該運算所得的結果和進行一次該運算所得的結果是一樣的，那麼我們就稱該運算是冪等的。 比如絕對值運算就是一個例子，在實數集中，有abs(a) = abs(abs(a)) 。

對於雙目運算，則要求當參與運算的兩個值是等值的情況下，如果滿足運算結果與參與運算的兩個值相等，則稱該運算冪等，如求兩個數的最大值的函數，有在實數集中冪等，即max(x,x) = x 。

看完上述解釋後，應該可以理解GET冪等的含義了。

但在實際應用中，以上2條規定並沒有這麼嚴格。引用別人文章的例子：比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。從根本上說，如果目標是當用戶打開一個鏈接時，他可以確信從自身的角度來看沒有改變資源即可。

根據HTTP規範，POST表示可能修改變服務器上的資源的請求 。繼續引用上面的例子：還是新聞以網站為例，讀者對新聞發表自己的評論應該通過POST實現，因為在評論提交後站點的資源已經不同了，或者說資源被修改了。

上面大概說了一下HTTP規範中，GET和POST的一些原理性的問題。但在實際的做的時候，很多人卻沒有按照HTTP規範去做，導致這個問題的原因有很多，比如說：

1.很多人貪方便，更新資源時用了GET，因為用POST必須要到FORM（表單），這樣會麻煩一點。

2.對資源的增，刪，改，查操作，其實都可以通過GET/POST完成，不需要用到PUT和DELETE。

3.另外一個是，早期的但是Web MVC框架設計者們並沒有有意識地將URL當作抽象的資源來看待和設計 。還有一個較為嚴重的問題是傳統的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。

* 簡單解釋一下MVC：MVC本來是存在於Desktop程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVC的目的是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。

以上3點典型地描述了老一套的風格（沒有嚴格遵守HTTP規範），隨着架構的發展，現在出現REST(Representational State Transfer)，一套支持HTTP規範的新風格，這裡不多說了，可以參考《RESTful Web Services》。

二 表現形式區別

搞清了兩者的原理區別，我們再來看一下他們實際應用中的區別：

為了理解兩者在傳輸過程中的不同，我們先看一下HTTP協議的格式：

HTTP請求：

request line          //http請求行

headers               //http請求消息報頭

blank line             // 回 車 換行

[request-body]     //http請求正文

在HTTP請求中，第一行必須是一個請求行（request line），用來說明請求類型、要訪問的資源以及使用的HTTP版本。緊接着是一個首部（header）小節，用來說明服務器要使用的附加信息。在首部之後是一個空行，再此之後可以添加任意的其他數據[稱之為主體（body）]。

GET與POST方法實例：

GET /books/?sex=manname=Professional HTTP/1.1

Host: 

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)

Gecko/20050225 Firefox/1.0.1

Connection: Keep-Alive

POST / HTTP/1.1

Host: 

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)

Gecko/20050225 Firefox/1.0.1

Content-Type: application/x-www-form-urlencoded

Content-Length: 40

Connection: Keep-Alive

（—-此處空一行—-）

name=Professional%20Ajaxpublisher=Wiley

有了以上對HTTP請求的了解和示例，我們再來看兩種提交方式的區別：

（1）GET提交，請求的數據會附在URL之後（就是把數據放置在HTTP協議頭中），以?分割URL和傳輸數據，多個參數用連接；例 如：login.action?name=hydddpassword=idontknowverify=%E4%BD%A0 %E5%A5%BD。如果數據是英文字母/數字，原樣發送，如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進制表示的ASCII。

POST提交：把提交的數據放置在是HTTP包的包體中。上文示例中紅色字體標明的就是實際的傳輸數據

因此，GET提交的數據會在地址欄中顯示出來，而POST提交，地址欄不會改變

(2)傳輸數據的大小：首先聲明：HTTP協議沒有對傳輸的數據大小進行限制，HTTP協議規範也沒有對URL長度進行限制。

而在實際開發中存在的限制主要有：

GET:特定瀏覽器和服務器對URL長度有限制，例如 IE對URL長度的限制是2083字節(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操作系 統的支持。

因此對於GET提交時，傳輸數據就會受到URL長度的 限制。

POST:由於不是通過URL傳值，理論上數據不受 限。但實際各個WEB服務器會規定對post提交數據大小進行限制，Apache、IIS6都有各自的配置。

(3)安全性：

POST的安全性要比GET的安全性高。注意：這裡所說的安全性和上面GET提到的“安全”不是同個概念。上面 “安全”的含義僅僅是不作數據修 改，而這 里安全的含義是真正的Security的含義，比如：通過GET提交數據，用戶名和密碼將明文出現在URL上，因為(1)登錄頁面有可能被瀏覽器緩存， (2)其他人查看瀏覽器的歷史紀錄，那麼別人就可以拿到你的賬號和密碼了，除此之外，使用GET提交數據還可能會造成Cross-site request forgery攻擊

（4）Http get,post,soap協議都是在http上運行的

1）get：請求參數是作為一個key/value對的序列（查詢字符串）附加到URL上的

查詢字符串的長度受到web瀏覽器和web服務器的限制（如IE最多支持2048個字符），不適合傳輸大型數據集同時，它很不安全

2）post：請求參數是在http標題的一個不同部分（名為entity body）傳輸的，這一部分用來傳輸表單信息，因此必須將Content-type設置為:application/x-www-form- urlencoded。post設計用來支持web窗體上的用戶字段，其參數也是作為key/value對傳輸。

但是：它不支持複雜數據類型，因為post沒有定義傳輸數據結構的語義和規則。

3）soap：是http post的一個專用版本，遵循一種特殊的xml消息格式

Content-type設置為: text/xml   任何數據都可以xml化

三 HTTP響應 

1．HTTP響應格式：

status line          //http響應狀態行

headers             //http響應消息報頭

blank line            //回車換行

[response-body]  //http響應正文

在響應中唯一真正的區別在於第一行中用狀態信息代替了請求信息。狀態行（status line）通過提供一個狀態碼來說明所請求的資源情況。 

HTTP響應實例：

HTTP/1.1 200 OKDate: Sat, 31 Dec 2005 23:59:59 GMTContent-Type: text/html;charset=ISO-8859-1 Content-Length: 122

＜html＞

 ＜head＞

  ＜title＞Wrox Homepage＜/title＞

 ＜/head＞

 ＜body＞＜!– body goes here –＞＜/body＞

＜/html＞

2．最常用的狀態碼有：

◆200 (OK): 找到了該資源，並且一切正常。

◆304 (NOT MODIFIED): 該資源在上次請求之後沒有任何修改。這通常用於瀏覽器的緩存機制。

◆401 (UNAUTHORIZED): 客戶端無權訪問該資源。這通常會使得瀏覽器要求用戶輸入用戶名和密碼，以登錄到服務器。

◆403 (FORBIDDEN): 客戶端未能獲得授權。這通常是在401之後輸入了不正確的用戶名或密碼。

◆404 (NOT FOUND): 在指定的位置不存在所申請的資源.

四 完整示例

例子：

HTTP GET 發送

GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=stringPWD=stringOrderConfirmation=string HTTP/1.1

Host: api.efxnow.com

Response :

HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: length

?xml version=”1.0″ encoding=”utf-8″?

objPlaceOrderResponse xmlns=””

Successboolean/Success

ErrorDescriptionstring/ErrorDescription

ErrorNumberint/ErrorNumber

CustomerOrderReferencelong/CustomerOrderReference

OrderConfirmationstring/OrderConfirmation

CustomerDealRefstring/CustomerDealRef

/objPlaceOrderResponse

Http Post 發送

POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1

Host: api.efxnow.com

Content-Type: application/x-www-form-urlencoded

Content-Length: length

UserID=stringPWD=stringOrderConfirmation=string

Response : 

HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: length

?xml version=”1.0″ encoding=”utf-8″?

objPlaceOrderResponse xmlns=””

Successboolean/Success

ErrorDescriptionstring/ErrorDescription

ErrorNumberint/ErrorNumber

CustomerOrderReferencelong/CustomerOrderReference

OrderConfirmationstring/OrderConfirmation

CustomerDealRefstring/CustomerDealRef

/objPlaceOrderResponse

SOAP 1.2 

發送

POST /DEMOWebServices2.8/Service.asmx HTTP/1.1

Host: api.efxnow.com

Content-Type: application/soap+xml; charset=utf-8

Content-Length: length

?xml version=”1.0″ encoding=”utf-8″?

soap12:Envelope xmlns:xsi=”” xmlns:xsd=”” xmlns:soap12=””

soap12:Body

CancelOrder xmlns=””

UserIDstring/UserID

PWDstring/PWD

OrderConfirmationstring/OrderConfirmation

/CancelOrder

/soap12:Body

/soap12:Envelope

Response : 

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset=utf-8

Content-Length: length

?xml version=”1.0″ encoding=”utf-8″?

soap12:Envelope xmlns:xsi=”” xmlns:xsd=”” xmlns:soap12=””

soap12:Body

CancelOrderResponse xmlns=””

CancelOrderResult

Successboolean/Success

ErrorDescriptionstring/ErrorDescription

ErrorNumberint/ErrorNumber

CustomerOrderReferencelong/CustomerOrderReference

OrderConfirmationstring/OrderConfirmation

CustomerDealRefstring/CustomerDealRef

/CancelOrderResult

/CancelOrderResponse

/soap12:Body

/soap12:Envelope

1. get是從服務器上獲取數據，post是向服務器傳送數據。 get 和 post只是一種傳遞數據的方式，get也可以把數據傳到服務器，他們的本質都是發送請求和接收結果。只是組織格式和數據量上面有差別，http協議裡面有介紹

2. get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中可以看到。post是通過HTTP post機制，將表單內各個字段與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。 

因為get設計成傳輸小數據，而且最好是不修改服務器的數據，所以瀏覽器一般都在地址欄裡面可以看到，但post一般都用來傳遞大數據，或比較隱私的數據，所以在地址欄看不到，能不能看到不是協議規定，是瀏覽器規定的。

3. 對於get方式，服務器端用Request.QueryString獲取變量的值，對於post方式，服務器端用Request.Form獲取提交的數據。 

沒明白，怎麼獲得變量和你的服務器有關，和get或post無關，服務器都對這些請求做了封裝

4. get傳送的數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。 

post基本沒有限制，我想大家都上傳過文件，都是用post方式的。只不過要修改form裡面的那個type參數

5. get安全性非常低，post安全性較高。 

如果沒有加密，他們安全級別都是一樣的，隨便一個監聽器都可以把所有的數據監聽到，不信你自己下一個監聽網絡資源的軟件，

一起討論下，消息冪等（去重）通用解決方案

消息中間件是分布式系統常用的組件，無論是異步化、解耦、削峰等都有廣泛的應用價值。我們通常會認為，消息中間件是一個可靠的組件——這裡所謂的可靠是指，只要我把消息成功投遞到了消息中間件，消息就不會丟失，即消息肯定會至少保證消息能被消費者成功消費一次，這是消息中間件最基本的特性之一，也就是我們常說的“AT LEAST ONCE”，即消息至少會被“成功消費一遍”。

舉個例子，一個消息M發送到了消息中間件，消息投遞到了消費程序A，A接受到了消息，然後進行消費，但在消費到一半的時候程序重啟了，這時候這個消息並沒有標記為消費成功，這個消息還會繼續投遞給這個消費者，直到其消費成功了，消息中間件才會停止投遞。

然而這種可靠的特性導致，消息可能被多次地投遞。舉個例子，還是剛剛這個例子，程序A接受到這個消息M並完成消費邏輯之後，正想通知消息中間件“我已經消費成功了”的時候，程序就重啟了，那麼對於消息中間件來說，這個消息並沒有成功消費過，所以他還會繼續投遞。這時候對於應用程序A來說，看起來就是這個消息明明消費成功了，但是消息中間件還在重複投遞。

這在RockectMQ的場景來看，就是同一個messageId的消息重複投遞下來了。

基於消息的投遞可靠（消息不丟）是優先級更高的，所以消息不重的任務就會轉移到應用程序自我實現，這也是為什麼RocketMQ的文檔里強調的，消費邏輯需要自我實現冪等。背後的邏輯其實就是：不丟和不重是矛盾的（在分布式場景下），但消息重複是有解決方案的，而消息丟失是很麻煩的。

例如：假設我們業務的消息消費邏輯是：插入某張訂單表的數據，然後更新庫存：

要實現消息的冪等，我們可能會採取這樣的方案：

這對於很多情況下，的確能起到不錯的效果，但是在並發場景下，還是會有問題。

假設這個消費的所有代碼加起來需要1秒，有重複的消息在這1秒內（假設100毫秒）內到達（例如生產者快速重發，Broker重啟等），那麼很可能，上面去重代碼裡面會發現，數據依然是空的（因為上一條消息還沒消費完，還沒成功更新訂單狀態），

那麼就會穿透掉檢查的擋板，最後導致重複的消息消費邏輯進入到非冪等安全的業務代碼中，從而引發重複消費的問題（如主鍵衝突拋出異常、庫存被重複扣減而沒釋放等）

要解決上面並發場景下的消息冪等問題，一個可取的方案是開啟事務把select 改成 select for update語句，把記錄進行鎖定。

但這樣消費的邏輯會因為引入了事務包裹而導致整個消息消費可能變長，並發度下降。

當然還有其他更高級的解決方案，例如更新訂單狀態採取樂觀鎖，更新失敗則消息重新消費之類的。但這需要針對具體業務場景做更複雜和細緻的代碼開發、庫表設計，不在本文討論的範圍。

但無論是select for update， 還是樂觀鎖這種解決方案，實際上都是基於業務表本身做去重，這無疑增加了業務開發的複雜度， 一個業務系統裡面很大部分的請求處理都是依賴MQ的，如果每個消費邏輯本身都需要基於業務本身而做去重/冪等的開發的話，這是繁瑣的工作量。本文希望 探索 出一個通用的消息冪等處理的方法，從而抽象出一定的工具類用以適用各個業務場景。

在消息中間件里，有一個投遞語義的概念，而這個語義里有一個叫”Exactly Once”，即消息肯定會被成功消費，並且只會被消費一次。以下是阿里雲里對Exactly Once的解釋：

在我們業務消息冪等處理的領域內，可以認為業務消息的代碼肯定會被執行，並且只被執行一次，那麼我們可以認為是Exactly Once。

但這在分布式的場景下想找一個通用的方案幾乎是不可能的。不過如果是針對基於數據庫事務的消費邏輯，實際上是可行的。

假設我們業務的消息消費邏輯是：更新MySQL數據庫的某張訂單表的狀態：

要實現Exaclty Once即這個消息只被消費一次（並且肯定要保證能消費一次），我們可以這樣做：在這個數據庫中增加一個消息消費記錄表，把消息插入到這個表，並且把原來的訂單更新和這個插入的動作放到同一個事務中一起提交，就能保證消息只會被消費一遍了。

1、開啟事務

2、插入消息表（處理好主鍵衝突的問題）

3、更新訂單表（原消費邏輯）

4、提交事務

說明：

1、這時候如果消息消費成功並且事務提交了，那麼消息表就插入成功了，這時候就算RocketMQ還沒有收到消費位點的更新再次投遞，也會插入消息失敗而視為已經消費過，後續就直接更新消費位點了。這保證我們消費代碼只會執行一次。2、如果事務提交之前服務掛了（例如重啟），對於本地事務並沒有執行所以訂單沒有更新，消息表也沒插入成功；而對於RocketMQ服務端來說，消費位點也沒更新，所以消息還會繼續投遞下來，投遞下來發現這個消息插入消息表也是成功的，所以可以繼續消費。這保證了消息不丟失。

事實上，阿里雲ONS的EXACTLY-ONCE語義的實現上，就是類似這個方案基於數據庫的事務特性實現的。更多詳情可參考：

基於這種方式，的確這是有能力拓展到不同的應用場景，因為他的實現方案與具體業務本身無關——而是依賴一個消息表。

但是這裡有它的局限性

1、消息的消費邏輯必須是依賴於關係型數據庫事務。如果消費的消費過程中還涉及其他數據的修改，例如Redis這種不支持事務特性的數據源，則這些數據是不可回滾的。

2、數據庫的數據必須是在一個庫，跨庫無法解決

註：業務上，消息表的設計不應該以消息ID作為標識，而應該以業務的業務主鍵作為標識更為合理，以應對生產者的重發。阿里雲上的消息去重只是RocketMQ的messageId，在生產者因為某些原因手動重發（例如上游針對一個交易重複請求了）的場景下起不到去重/冪等的效果（因消息id不同）。

如上所述，這種方式Exactly Once語義的實現，實際上有很多局限性，這種局限性使得這個方案基本不具備廣泛應用的價值。並且由於基於事務，可能導致鎖表時間過長等性能問題。

例如我們以一個比較常見的一個訂單申請的消息來舉例，可能有以下幾步（以下統稱為步驟X）：

1、 檢查庫存（RPC）

2、 鎖庫存（RPC）

3、 開啟事務，插入訂單表（MySQL）

4、 調用某些其他下游服務（RPC）

5、 更新訂單狀態

6、 commit 事務（MySQL）

這種情況下，我們如果採取消息表+本地事務的實現方式，消息消費過程中很多子過程是不支持回滾的，也就是說就算我們加了事務，實際上這背後的操作並不是原子性的。怎麼說呢，就是說有可能第一條小在經歷了第二步鎖庫存的時候，服務重啟了，這時候實際上庫存是已經在另外的服務里被鎖定了，這並不能被回滾。當然消息還會再次投遞下來，要保證消息能至少消費一遍，換句話說，鎖庫存的這個RPC接口本身依舊要支持“冪等”。

再者，如果在這個比較耗時的長鏈條場景下加入事務的包裹，將大大的降低系統的並發。所以通常情況下，我們處理這種場景的消息去重的方法還是會使用一開始說的業務自己實現去重邏輯的方式，如前面加select for update，或者使用樂觀鎖。

那我們有沒有方法抽取出一個公共的解決方案，能兼顧去重、通用、高性能呢？

其中一個思路是把上面的幾步，拆解成幾個不同的子消息，例如：

1、庫存系統消費A：檢查庫存並做鎖庫存，發送消息B給訂單服務

2、訂單系統消費消息B：插入訂單表（MySQL），發送消息C給自己（下游系統）消費

3、下游系統消費消息C：處理部分邏輯，發送消息D給訂單系統

4、訂單系統消費消息D：更新訂單狀態

註：上述步驟需要保證本地事務和消息是一個事務的（至少是最終一致性的），這其中涉及到分布式事務消息相關的話題，不在本文論述。

可以看到這樣的處理方法會使得每一步的操作都比較原子，而原子則意味着是小事務，小事務則意味着使用消息表+事務的方案顯得可行。

然而，這太複雜了！這把一個本來連續的代碼邏輯割裂成多個系統多次消息交互！那還不如業務代碼層面上加鎖實現呢。

上面消息表+本地事務的方案之所以有其局限性和並發的短板，究其根本是因為它依賴於關係型數據庫的事務，且必須要把事務包裹於整個消息消費的環節。

如果我們能不依賴事務而實現消息的去重，那麼方案就能推廣到更複雜的場景例如：RPC、跨庫等。

例如，我們依舊使用消息表，但是不依賴事務，而是針對消息表增加消費狀態，是否可以解決問題呢？

67_1.png

以上是去事務化後的消息冪等方案的流程，可以看到，此方案是無事務的，而是針對消息表本身做了狀態的區分：消費中、消費完成。只有消費完成的消息才會被冪等處理掉。而對於已有消費中的消息，後面重複的消息會觸發延遲消費（在RocketMQ的場景下即發送到RETRY TOPIC），之所以觸發延遲消費是為了控制並發場景下，第二條消息在第一條消息沒完成的過程中，去控制消息不丟（如果直接冪等，那麼會丟失消息（同一個消息id的話），因為上一條消息如果沒有消費完成的時候，第二條消息你已經告訴broker成功了，那麼第一條消息這時候失敗broker也不會重新投遞了）

上面的流程不再細說，後文有github源碼的地址，讀者可以參考源碼的實現，這裡我們回頭看看我們一開始想解決的問題是否解決了：

1、 消息已經消費成功了，第二條消息將被直接冪等處理掉（消費成功）。

2、 並發場景下的消息，依舊能滿足不會出現消息重複，即穿透冪等擋板的問題。

3、 支持上游業務生產者重發的業務重複的消息冪等問題。

關於第一個問題已經很明顯已經解決了，在此就不討論了。

關於第二個問題是如何解決的？主要是依靠插入消息表的這個動作做控制的，假設我們用MySQL作為消息表的存儲媒介（設置消息的唯一ID為主鍵），那麼插入的動作只有一條消息會成功，後面的消息插入會由於主鍵衝突而失敗，走向延遲消費的分支，然後後面延遲消費的時候就會變成上面第一個場景的問題。

關於第三個問題，只要我們設計去重的消息鍵讓其支持業務的主鍵（例如訂單號、請求流水號等），而不僅僅是messageId即可。所以也不是問題。

如果細心的讀者可能會發現這裡實際上是有邏輯漏洞的，問題出在上面聊到的個三問題中的第2個問題（並發場景），在並發場景下我們依賴於消息狀態是做並發控制使得第2條消息重複的消息會不斷延遲消費（重試）。但如果這時候第1條消息也由於一些異常原因（例如機器重啟了、外部異常導致消費失敗）沒有成功消費成功呢？也就是說這時候延遲消費實際上每次下來看到的都是 消費中 的狀態，最後消費就會被視為消費失敗而被投遞到死信Topic中（RocketMQ默認可以重複消費16次）。

有這種顧慮是正確的！對於此，我們解決的方法是，插入的消息表必須要帶一個最長消費過期時間，例如10分鐘，意思是如果一個消息處於 消費中 超過10分鐘，就需要從消息表中刪除（需要程序自行實現）。所以最後這個消息的流程會是這樣的：

67_2.png

我們這個方案實際上沒有事務的，只需要一個存儲的中心媒介，那麼自然我們可以選擇更靈活的存儲媒介，例如Redis。使用Redis有兩個好處：

1、性能上損耗更低

2、上面我們講到的超時時間可以直接利用Redis本身的ttl實現

當然Redis存儲的數據可靠性、一致性等方面是不如MySQL的，需要用戶自己取捨。

以上方案針對RocketMQ的Java實現已經開源放到Github中，具體的使用文檔可以參考 ，

以下僅貼一個Readme中利用Redis去重的使用樣例，用以意業務中如果使用此工具加入消息去重冪等的是多麼簡單：

以上代碼大部分是原始RocketMQ的必須代碼，唯一需要修改的僅僅是創建一個 DedupConcurrentListener 示例，在這個示例中指明你的消費邏輯和去重的業務鍵（默認是messageId）。

更多使用詳情請參考Github上的說明。

實現到這裡，似乎方案挺完美的，所有的消息都能快速的接入去重，且與具體業務實現也完全解耦。那麼這樣是否就完美的完成去重的所有任務呢？

很可惜，其實不是的。原因很簡單：因為要保證消息至少被成功消費一遍，那麼消息就有機會消費到一半的時候失敗觸發消息重試的可能。還是以上面的訂單流程X：

1、 檢查庫存（RPC）

2、 鎖庫存（RPC）

3、 開啟事務，插入訂單表（MySQL）

4、 調用某些其他下游服務（RPC）

5、 更新訂單狀態

6、 commit 事務（MySQL）

當消息消費到步驟3的時候，我們假設MySQL異常導致失敗了，觸發消息重試。因為在重試前我們會刪除冪等表的記錄，所以消息重試的時候就會重新進入消費代碼，那麼步驟1和步驟2就會重新再執行一遍。如果步驟2本身不是冪等的，那麼這個業務消息消費依舊沒有做好完整的冪等處理。

那麼既然這個並不能完整的完成消息冪等，還有什麼價值呢？價值可就大了！雖然這不是解決消息冪等的銀彈（事實上，軟件工程領域裡基本沒有銀彈），但是他能以便捷的手段解決：

1、各種由於Broker、負載均衡等原因導致的消息重投遞的重複問題

2、各種上游生產者導致的業務級別消息重複問題

3、重複消息並發消費的控制窗口問題，就算重複，重複也不可能同一時間進入消費邏輯

也就是說，使用這個方法能保證正常的消費邏輯場景下（無異常，無異常退出），消息的冪等工作全部都能解決，無論是業務重複，還是rocketmq特性帶來的重複。

事實上，這已經能解決99%的消息重複問題了，畢竟異常的場景肯定是少數的。那麼如果希望異常場景下也能處理好冪等的問題，可以做以下工作降低問題率：

1、消息消費失敗做好回滾處理。如果消息消費失敗本身是帶回滾機制的，那麼消息重試自然就沒有副作用了。

2、消費者做好優雅退出處理。這是為了儘可能避免消息消費到一半程序退出導致的消息重試。

3、一些無法做到冪等的操作，至少要做到終止消費並告警。例如鎖庫存的操作，如果統一的業務流水鎖成功了一次庫存，再觸發鎖庫存，如果做不到冪等的處理，至少要做到消息消費觸發異常（例如主鍵衝突導致消費異常等）

4、在#3做好的前提下，做好消息的消費監控，發現消息重試不斷失敗的時候，手動做好#1的回滾，使得下次重試消費成功

如何判斷請求的冪等性 java

x請求的報文頭不一樣，通過如下

Java代碼

String requestType = request.getHeader(“X-Requested-With”);

如果requestType能拿到值，並且值為XMLHttpRequest,表示客戶端的請求為異步請求，那自然是ajax請求了，反之如果為null,則是普通的請求

java程序領取優惠卷,高並發下怎麼避免領取量超過預發量

基本思路是：鎖+冪等性

具體實現：

使用redis的decr （對key對應的數字做減1操作。如果key不存在，那麼在操作之前，這個key對應的值會被置為0。如果key有一個錯誤類型的value或者是一個不能表示成數字的字符串，就返回錯誤。這個操作最大支持在64位有符號的整型數字。）可以實現原子性的遞增遞減操作控制優惠碼不超送，然後給每個用戶維護一個userid+優惠碼活動的key保證冪等性，只要redis存在這種key，那就代表已經領取了，具體的優惠碼分發可以異步執行。為了避免競爭（同一個用戶，多個設備同時領取），參考：網頁鏈接