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