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