本文中只是把我的一些使用JMS的心得寫出來,并非什么"最佳實踐",有錯誤的請大家盡管拍磚!
1.消息類型的選擇
Java的JMS消息類型有文本類型,對象類型,字節(jié)類型,流類型,XML類型,在實際項目中,用的最多的是文本類型,對象類型和xml類型的消息.建議最好不用對象類型,因為如果用對象類型的話,調(diào)試的時候是很麻煩的,首先你必須要寫專門的測試代碼用來發(fā)送消息,第二,必須要管理對象所屬的類的不同版本,第三,不方便查看queue或者topic中的消息內(nèi)容.而如果使用文本類型或者xml類型的消息,那么可以很容易的通過JMS中間件提供的一些管理工具來發(fā)送測試消息,查看消息內(nèi)容,并且更加容易管理不同版本之間的兼容性.如果一定要用對象類型消息的話,建議使用xstream把對象轉(zhuǎn)化為xml
2.是使用queue還是topic?
這兩者的定義是很清楚的,也很容易區(qū)分.但是在實際項目中,如何來取舍呢?我的建議是盡量用queue.如果你的項目用到了JMS,那么你的系統(tǒng)也應該是到了需要部署在集群環(huán)境的規(guī)模了.用topic在集群環(huán)境下會帶來很多麻煩.舉個簡單的例子,如果你是用MDB來處理topic的消息,你有一個MDB名為SampleMDB,它以集群的方式分別部署在A服務器和B服務器上.那么有可能同一條topic消息被同一個MDB處理兩次.雖然一些JMS中間件提供商為解決這種問題提供了一些解決方案,例如把subsriber分組,但是它為開發(fā)和調(diào)試都帶來了很大的麻煩.topic消息的處理也要比queue的復雜,很難跟蹤topic消息的處理過程.
那么,如果不用topic的話,怎么來實現(xiàn)topic這種性質(zhì)的消息處理呢?可以寫一個消息轉(zhuǎn)發(fā)器,把一個queue上的消息轉(zhuǎn)發(fā)給所有關(guān)注這個queue的其它queue中.例如,有一個queue,名為SampleQ1,一個消息發(fā)送者sender,一個消息轉(zhuǎn)發(fā)器router,有三個handler A,B,C需要處理這個queue中的消息.那么,sender發(fā)送消息到SampleQ1,router接收SampleQ1的消息后分別發(fā)送到SampleQ1_A,SampleQ1_B,SampleQ1_C,handler A,B,C分別從隊列SampleQ1_A,SampleQ1_B,SampleQ1_C中接收消息.
3.用JMS來解決什么問題?
一提起JMS可以做什么,第一想到的就是異步處理.面試的時候問JMS可以做什么?大多數(shù)的回答是:用JMS來異步發(fā)送郵件!(到底應該怎么樣構(gòu)建一個郵件發(fā)送系統(tǒng)不是本文的主題,以后有時間我會專門來談談在我的項目中,我是怎么來設(shè)計郵件發(fā)送系統(tǒng)的).其實,還可以用JMS來解決很多復雜的問題,例如分布,并發(fā),系統(tǒng)解耦,負載均衡,熱部署,觸發(fā)器等等,這些復雜的問題因為引入了JMS而變的更加簡單.下面簡單介紹下解決分布,并發(fā)問題的場景.
3.1 用JMS來解決并發(fā)問題
queue的概念大家都很清楚了,那就是queue里的一條消息只會被一個消息接收者處理.基于這個概念,我們可以在系統(tǒng)中對并發(fā)要求很嚴格的模塊中引入JMS的使用.例如,系統(tǒng)的送積分,一般這個模塊是用一個定時器,例如quartz,每天定期查詢數(shù)據(jù)庫,如果發(fā)現(xiàn)有滿足條件的記錄,那么就把積分送給會員.如果同時有多個quartz在運行,那么必須嚴格控制防止并發(fā)的對同一條記錄送多次積分.解決這個問題有很多方法,可以通過業(yè)務的設(shè)計,系統(tǒng)的部署,數(shù)據(jù)庫的設(shè)計,事務的控制等方法來實現(xiàn),在這里提一個用JMS來解決問題的方法:在插入記錄的同時發(fā)送一個queue的消息.這樣即使有多個送積分的MDB實例在運行,也只會被一個實例處理.
3.2用JMS來解決分布的問題
解決分布有兩種類型,第一種是指消息是集中的,但消息的處理是分布的.例如,系統(tǒng)可能會被分為前臺與后臺,這兩個系統(tǒng)是部署在不同的網(wǎng)段里的.那么怎么把前臺發(fā)生的業(yè)務通知后臺系統(tǒng)呢?當然,可以通過一個類似定時器的玩意定期去數(shù)據(jù)庫查詢.但這種方式要么就是浪費系統(tǒng)資源,可能在定期查詢中80%的時間都是在做無用功,要么就是業(yè)務請求沒有被及時處理.,因為定期的時間總是有一個時間間隔的.用JMS來處理這個問題會怎么樣呢?前臺系統(tǒng)在處理完業(yè)務請求后的同時發(fā)送一個消息到queue中,后臺系統(tǒng)的消息接收者接收到消息后立即處理.這里消息的處理也可能有一定的延期,但這主要取決于消息服務器的硬件能力,網(wǎng)絡帶寬,消息接收者的處理速度等.
第二中是指消息也是分布的.很多消息中間件都提供了消息路由的功能,即消息發(fā)送到一個消息服務器后,這個消息服務器根據(jù)定義的規(guī)則再把這條消息路由轉(zhuǎn)發(fā)到其它的消息服務器.例如,可能在北京的一個數(shù)據(jù)中心部署了數(shù)據(jù)采集系統(tǒng),采集到數(shù)據(jù)后以消息的方式發(fā)送到消息服務器,然后消息服務器再把這條消息路由到上海的數(shù)據(jù)中心,再由上海數(shù)據(jù)中心部署的數(shù)據(jù)處理系統(tǒng)來處理這條消息.
4.JMS與事務,一定要用JTA事務嗎
很多人接觸到JTA事務都是從用JMS開始的,畢竟同時要連多個數(shù)據(jù)庫的的系統(tǒng)并不是那么的多!而要用JTA事務的話,就得要在笨重的應用服務器中部署.(當然,你也可以用類似atomikos的輕量級JTA事務管理器),更重要的是,并不是事務本身的技術(shù)有多復雜,而是事務的界定,這種事務的界定有時都不是程序員能決定的事情,需要在設(shè)計的時候就要考慮清楚,甚至可能還需要業(yè)務人員的參與.(題外話:經(jīng)常問面試的,用spring的aop做什么?大多數(shù)答:用來管理事務!事務要真這么簡單該多好啊!)
我也不是要反對用JTA事務,而是要說明一下,用JMS,并非一定要用JTA事務.這可以分為三種場景:
一,必須用JTA事務,這種情況下,一般消息的接收者只從消息本身獲得數(shù)據(jù)并進行處理.所以必須要保證消息的發(fā)送與所依賴的業(yè)務保持一致.
二.不需要用事務,這種情況下, 要么是業(yè)務無關(guān)緊要,例如用JMS來記錄日志.要么是發(fā)送的消息僅僅是一個作為后續(xù)業(yè)務處理的一個觸發(fā)器!消息接收者僅僅是從消息中獲得一個id,然后根據(jù)這個id去查詢所依賴的其它數(shù)據(jù)進行業(yè)務處理.即使消息丟失也沒關(guān)系,可以通過其它的機制來補償.
三.消息丟失可以通過補償事務來完成.這個依賴與具體實現(xiàn),就不詳細說了.
5.處理消息永遠比發(fā)送消息慢!
要保證你的JMS應用穩(wěn)定的運行,那么你必須在開發(fā),部署的時候時刻重視這個問題.
首先,需要把發(fā)送消息的連接池與接收消息的連接池分開.以避免接收消息的連接過過而導致發(fā)送消息的應用拿不到連接.
在一個連接上并發(fā)的處理消息,而不是連接打開,處理一個消息,馬上關(guān)閉連接.
合理的設(shè)置消息的過期時間,否則消息日積月累,最終超出queue的size
對于非關(guān)鍵業(yè)務的消息處理,可以采用異步處理的方法:接收到消息后并不是立刻處理,而是放到一個任務池或者線程池中處理.如果消息處理失敗,則把消息重新發(fā)送回隊列中.