◆呂德奎 崔艷軍

（中國(guó)電子科技集團(tuán)公司第二十八研究所 江蘇 210007）

開(kāi)源消息中間件復(fù)雜并發(fā)連接控制的研究與實(shí)現(xiàn)

◆呂德奎 崔艷軍

（中國(guó)電子科技集團(tuán)公司第二十八研究所 江蘇 210007）

消息中間件（Message-Oriented Middleware）是解決異構(gòu)分布式系統(tǒng)中通信與排隊(duì)的中間件技術(shù)，ActiveMQ是一款基于Java語(yǔ)言的JMS規(guī)范的技術(shù)實(shí)現(xiàn)，是一款企業(yè)級(jí)常用的JMS產(chǎn)品。本文研究了當(dāng)前ActiveMQ在涉及多廠家、跨平臺(tái)應(yīng)用時(shí)，由于客戶端連接技術(shù)不統(tǒng)一、連接不規(guī)范、連接后不釋放、數(shù)據(jù)格式發(fā)送不符合規(guī)范等因素，碰到的ActiveMQ服務(wù)中心因阻塞而宕掉的問(wèn)題基礎(chǔ)上，分析了當(dāng)前幾種常用解決手段；依據(jù)JMX底層規(guī)范與實(shí)現(xiàn)，設(shè)計(jì)并實(shí)現(xiàn)了一種基于JMX的客戶端連接問(wèn)題的解決方法與處理規(guī)范、提高ActiveMQ服務(wù)中心的運(yùn)行穩(wěn)定性。經(jīng)過(guò)大量的實(shí)際應(yīng)用，在數(shù)百家客戶端并發(fā)連接時(shí)、消息量達(dá)5千/秒以下時(shí)能夠保證ActiveMQ服務(wù)中心長(zhǎng)期有效的運(yùn)行，從而提高了企業(yè)應(yīng)用的基礎(chǔ)數(shù)據(jù)的連續(xù)性與穩(wěn)定性。

ActiveMQ；消息總線；JMX；JMS；并發(fā)連接優(yōu)化

0 引言

隨著信息網(wǎng)絡(luò)的迅速發(fā)展，越來(lái)越多的公司、單位、組織建立了各種應(yīng)用系統(tǒng)和資源系統(tǒng)，這些系統(tǒng)對(duì)推動(dòng)信息化的發(fā)展起了舉足輕重的作用，然而這些系統(tǒng)可能是建立在不同的環(huán)境下，如何進(jìn)行互操作和資源共享，成為了迫切需要解決的問(wèn)題。

現(xiàn)有的應(yīng)用系統(tǒng)中，不同應(yīng)用之間通信存在以下問(wèn)題：一是通信雙方的環(huán)境如操作系統(tǒng)、協(xié)議等不同可能造成雙方無(wú)法進(jìn)行數(shù)據(jù)交換；二是服務(wù)器必須與客戶端保持連接通信的狀態(tài)，被動(dòng)的等待遠(yuǎn)程客戶端的通信請(qǐng)求，因此性能隨著用戶數(shù)目的增加而不斷下降；三是存在因多用戶、多數(shù)據(jù)庫(kù)的連接，而導(dǎo)致系統(tǒng)死鎖和崩潰的潛在可能；四是明確發(fā)送和接收雙方調(diào)用的接口，一旦一方發(fā)生變化，必須在第一時(shí)間通知對(duì)方，否則會(huì)造成數(shù)據(jù)的丟失和通信的阻礙；五是程序更新維護(hù)難，一旦程序的變更，就需要對(duì)系統(tǒng)進(jìn)行重大修改，增加了維護(hù)和管理難度。

為解決以上問(wèn)題，引進(jìn)了一個(gè)“中間層”，將系統(tǒng)的表示層、邏輯層和數(shù)據(jù)層分隔開(kāi)來(lái)，成為獨(dú)立的單元，這個(gè)“中間層”就是中間件。系統(tǒng)的開(kāi)發(fā)者不需要將數(shù)據(jù)傳輸層和邏輯處理寫(xiě)入應(yīng)用程序中，只需通過(guò)中間件提供的API，將應(yīng)用程序與中間件、服務(wù)器有效快速的連接起來(lái)，實(shí)現(xiàn)資源的共享和互操作。

MOM（Message-Oriented Middleware（消息中間件）是解決異構(gòu)分布式系統(tǒng)中通信和排隊(duì)問(wèn)題的中間件技術(shù)，ActiveMQ則是MOM的一個(gè)跨語(yǔ)言跨平臺(tái)實(shí)現(xiàn)[7]，是一款常用的企業(yè)級(jí)JMS實(shí)現(xiàn)產(chǎn)品，因其實(shí)時(shí)性高，數(shù)據(jù)指標(biāo)接收速度快，取得了良好業(yè)績(jī)。但是當(dāng)涉及數(shù)百家單位、而且客戶端連接技術(shù)不統(tǒng)一、連接不規(guī)范、連接后不釋放、數(shù)據(jù)格式發(fā)送不符合規(guī)范等因素時(shí)，會(huì)導(dǎo)致中心ActiveMQ每隔一個(gè)月左右因阻塞而宕掉。

本文針對(duì)企業(yè)應(yīng)用現(xiàn)象，在分析了消息隊(duì)列中間件國(guó)內(nèi)外應(yīng)用現(xiàn)狀的基礎(chǔ)上，通過(guò)研究ActiveMQ的自身實(shí)現(xiàn)架構(gòu)，主要以JMX（Java Management Extensions，Java管理擴(kuò)展）為主，通過(guò)Java、ActiveMQ的內(nèi)部設(shè)計(jì)機(jī)制，實(shí)現(xiàn)一種按照預(yù)先設(shè)計(jì)的規(guī)則庫(kù)監(jiān)控各連接客戶端并對(duì)不規(guī)則連接進(jìn)行優(yōu)化處理方法，保證ActiveMQ中心能夠長(zhǎng)期穩(wěn)定的運(yùn)行，保障監(jiān)控?cái)?shù)據(jù)的順利接收，提高了企業(yè)應(yīng)用的數(shù)據(jù)連續(xù)性與穩(wěn)定性。

1 不規(guī)則并發(fā)連接問(wèn)題總計(jì)

ActiveMQ是基于Java JMS的分布式、跨平臺(tái)的消息應(yīng)用平臺(tái)軟件，其使用方法與數(shù)據(jù)庫(kù)類似，需要先建立連接（Connection）與會(huì)話（Session），訪問(wèn)結(jié)束時(shí)需要顯式關(guān)閉連接和連接會(huì)話，當(dāng)客戶端因?yàn)槟撤N因素未執(zhí)行關(guān)閉時(shí)將會(huì)導(dǎo)致ActiveMQ服務(wù)中心因最大連接數(shù)耗盡而導(dǎo)致服務(wù)宕掉，從而影響系統(tǒng)應(yīng)用、導(dǎo)致企業(yè)數(shù)據(jù)的丟失等問(wèn)題。

從上述分析可以了解，可以得出以下幾點(diǎn)結(jié)論：

（1）ActiveMQ本身有連接數(shù)限制，據(jù)測(cè)試并發(fā)連接數(shù)達(dá)1500以上時(shí)，ActiveMQ將會(huì)出現(xiàn)存取消息數(shù)據(jù)效率快速下降、無(wú)法建立新的連接等問(wèn)題。

（2）JVM有大小限制，據(jù)測(cè)試ActiveMQ最大JVM為1G左右。

（3）ActiveMQ 無(wú)法建立新連接，從而無(wú)法接收新的消息數(shù)據(jù)。

（4）ActiveMQ的連接不關(guān)閉，可能導(dǎo)致會(huì)話死鎖。

（5）ActiveMQ死鎖可能使消息數(shù)據(jù)無(wú)法消費(fèi)，長(zhǎng)期導(dǎo)致JVM溢出，甚至導(dǎo)致服務(wù)宕掉。

在上述結(jié)論基礎(chǔ)上，研究企業(yè)應(yīng)用現(xiàn)狀，可能導(dǎo)致大量并發(fā)數(shù)問(wèn)題產(chǎn)生的原因大致包括：

（1）客戶端連接Connection使用完未關(guān)閉，下次使用建立新的連接Connection。

（2）客戶端會(huì)話Session使用完未關(guān)閉，下次使用建立新的會(huì)話Session。

（3）客戶端連接采用連接池技術(shù)（Pooled Connection）時(shí)，當(dāng)應(yīng)用廠家眾多時(shí)如超過(guò)數(shù)百家，可能會(huì)導(dǎo)致連接資源耗盡。

（4）客戶端發(fā)送未使用隊(duì)列，導(dǎo)致JVM溢出，導(dǎo)致新的Connection無(wú)法建立等情況。

2 并發(fā)數(shù)優(yōu)化設(shè)計(jì)與實(shí)現(xiàn)

本節(jié)從ActiveMQ大量并發(fā)連接數(shù)下由于客戶端連接不合理帶來(lái)的問(wèn)題開(kāi)始分析，比較了幾種連接數(shù)問(wèn)題處理方法，最終提取并設(shè)計(jì)一種基于JMX規(guī)則庫(kù)的連接數(shù)優(yōu)化方案。

2.1 幾種優(yōu)化方法的比較

（1）顯式關(guān)閉連接和會(huì)話

顯式關(guān)閉的應(yīng)用場(chǎng)景為客戶端能夠顯式關(guān)閉連接和會(huì)話，企業(yè)應(yīng)用時(shí)尤其現(xiàn)代化信息系統(tǒng)建設(shè)涉及跨廠家、跨平臺(tái)，需要大量的應(yīng)用業(yè)務(wù)數(shù)據(jù)集成。各廠家接口開(kāi)發(fā)人員技術(shù)素質(zhì)參差不齊，多廠家接口開(kāi)發(fā)時(shí)間不一，尤其是測(cè)試不到位時(shí)，將會(huì)經(jīng)常導(dǎo)致連接溢出現(xiàn)象，從而需要廠商接口進(jìn)行進(jìn)一步的優(yōu)化。

ActiveMQ連接溢出將會(huì)對(duì)數(shù)據(jù)集成方帶來(lái)巨大應(yīng)用壓力，某一廠家接口問(wèn)題可能會(huì)導(dǎo)致全體數(shù)據(jù)的丟失，從而影響信息系統(tǒng)的整體使用。

此種辦法要求開(kāi)發(fā)商嚴(yán)格按照標(biāo)準(zhǔn)技術(shù)進(jìn)行開(kāi)發(fā)，此方式對(duì)集成方來(lái)說(shuō)屬于被動(dòng)式連接處理，實(shí)際情況因?yàn)榉N種因素可能短期內(nèi)不會(huì)有改善。

（2）Server端連接關(guān)閉

客戶端關(guān)閉方法是對(duì)技術(shù)的嚴(yán)格要求才能實(shí)現(xiàn)。Server端連接關(guān)閉由ActiveMQ服務(wù)應(yīng)用廠商進(jìn)行處理。Server端關(guān)閉的一般方法為，設(shè)計(jì)ActiveMQ 插件，利用ActiveMQ API提供的方法，獲得客戶端連接情況，并采取辦法進(jìn)行關(guān)閉。

利用服務(wù)端ActiveMQ API關(guān)閉連接Connection，在很大程度上能夠解決連接未關(guān)閉的問(wèn)題，而且此方法為主動(dòng)式的關(guān)閉。

但是當(dāng)連接出現(xiàn)死鎖時(shí)，服務(wù)端ActiveMQ API可能會(huì)失效。

2.2 優(yōu)化方法的設(shè)計(jì)與實(shí)現(xiàn)

從2.1節(jié)兩種常用的解決情況分析來(lái)看，效果并不理想，甚至非常耗費(fèi)聯(lián)合調(diào)試精力。本節(jié)采用另一種Java底層機(jī)制設(shè)計(jì)并實(shí)現(xiàn)ActiveMQ連接數(shù)及JVM占有量的監(jiān)控與管理方法。

JMX（jdk1.5默認(rèn)不開(kāi)啟，jdk1.6默認(rèn)開(kāi)啟）是一個(gè)為應(yīng)用程序、設(shè)備、系統(tǒng)等植入管理功能的框架。JMX可以跨越一系列異構(gòu)操作系統(tǒng)平臺(tái)、系統(tǒng)體系結(jié)構(gòu)和網(wǎng)絡(luò)傳輸協(xié)議，靈活的開(kāi)發(fā)無(wú)縫集成的系統(tǒng)、網(wǎng)絡(luò)和服務(wù)管理應(yīng)用。任何基于JVM運(yùn)行的應(yīng)用程序在一定條件下，不做任何代碼編寫(xiě)，即可使用JMX對(duì)JVM相關(guān)參數(shù)及方法進(jìn)行監(jiān)控與管理，如：關(guān)閉線程、查看堆棧量、查看進(jìn)程內(nèi)部類數(shù)量等。

ActiveMQ很好的實(shí)現(xiàn)了JMX協(xié)議，可以通過(guò)底層協(xié)議對(duì)其進(jìn)行監(jiān)控與管理。

（1）設(shè)計(jì)

基于JMX的ActiveMQ連接數(shù)優(yōu)化的設(shè)計(jì),主要包括：連接客戶端管理規(guī)則庫(kù)、ActiveMQ監(jiān)控參數(shù)、監(jiān)控處理方案等設(shè)計(jì)。

圖1 監(jiān)控示意圖

①連接客戶端管理規(guī)則庫(kù)

必須的定義：客戶端連接源（IP）、每個(gè)連接源最大連接數(shù)、處理規(guī)則、連接對(duì)象最近一次執(zhí)行時(shí)間、日志記錄規(guī)則等內(nèi)容。

客戶端連接源用于確保連接ActiveMQ服務(wù)中心的連接對(duì)象處于授權(quán)狀態(tài)，并且授權(quán)可建立的最大的連接數(shù)，如機(jī)器A最大可建立10個(gè)連接，機(jī)器B最大可建立5個(gè)連接。當(dāng)機(jī)器連接超過(guò)規(guī)則庫(kù)配置的最大連接數(shù)時(shí)，將會(huì)按照處理規(guī)則處理連接對(duì)象，如通過(guò)JMX技術(shù)手段，強(qiáng)制中斷該機(jī)器的所有連接對(duì)象等。

②ActiveMQ監(jiān)控參數(shù)

監(jiān)控參數(shù)：當(dāng)前連接數(shù)、當(dāng)前隊(duì)列堆積數(shù)、JVM內(nèi)存信息。監(jiān)控參數(shù)用于輔助查看當(dāng)前ActiveMQ運(yùn)行狀態(tài)，當(dāng)出現(xiàn)指標(biāo)偏離正?，F(xiàn)象時(shí)，可以為處理規(guī)則提供一定的處理參考依據(jù)。比如當(dāng)前連接數(shù)超過(guò)ActiveMQ警戒值時(shí)，通知處理規(guī)則進(jìn)行強(qiáng)制處理當(dāng)前所有連接對(duì)象，如中斷長(zhǎng)時(shí)間未執(zhí)行的連接對(duì)象。

③監(jiān)控處理方案

處理規(guī)則庫(kù)一次性初始化加載,對(duì)ActiveMQ以心跳時(shí)間片輪詢方式定期監(jiān)控其連接狀態(tài),當(dāng)異常時(shí),利用規(guī)則庫(kù)進(jìn)行處理。

（2）實(shí)現(xiàn)

根據(jù)規(guī)則配置庫(kù)，當(dāng)出現(xiàn)連接異常時(shí)，如超過(guò)機(jī)器授權(quán)最大連接數(shù)時(shí)或超過(guò)ActiveMQ警戒值時(shí),對(duì)ActiveMQ并發(fā)連接進(jìn)行規(guī)則處理,下面是獲取連接數(shù)以及強(qiáng)制關(guān)閉連接客戶端的偽代碼。

①查詢當(dāng)前所有連接對(duì)象

②強(qiáng)制停止連接對(duì)象

3 結(jié)束語(yǔ)

ActiveMQ是Apache旗下一款JMS工具，支持.NET、C++、Java等多種訪問(wèn)方式，在企業(yè)級(jí)系統(tǒng)中大量應(yīng)用，又因其實(shí)時(shí)性高，數(shù)據(jù)指標(biāo)接收速度快，取得了良好業(yè)績(jī)。但當(dāng)涉及數(shù)百家單位、而且客戶端連接不規(guī)范等因素時(shí)，會(huì)導(dǎo)致中心ActiveMQ服務(wù)阻塞而宕掉。本文通過(guò)以JMX的基礎(chǔ)技術(shù)，利用規(guī)則管理庫(kù)的思想，通過(guò)底層技術(shù)層面與業(yè)務(wù)規(guī)則相結(jié)合的手段，保障ActiveMQ中心在連接Connection問(wèn)題下能夠長(zhǎng)期穩(wěn)定的運(yùn)行，保障監(jiān)控?cái)?shù)據(jù)的順利接收。與此同時(shí)，本文的設(shè)計(jì)思路可為其他Java應(yīng)用提供了一個(gè)良好的參考與借鑒。

另外，本文僅對(duì)并發(fā)連接數(shù)及相關(guān)的狀態(tài)做了一定研究與實(shí)驗(yàn)，后續(xù)需要進(jìn)一步對(duì)其他參數(shù)進(jìn)行研究，爭(zhēng)取實(shí)現(xiàn)ActiveMQ全方位管理，達(dá)到更好的應(yīng)用效果。

[1]Sun Mierosystems.Java Message Service Specifi ca-tion. http://java.sun.com/Products/ims.

[2]Apache ActiveMQ.http://activemq.apache.org.

[3]邱云.基于JMS的信息發(fā)布平臺(tái)的研究與實(shí)現(xiàn)[D].電子科技大學(xué)，2005.

[4]汪紅兵，佘春東，范植華，李磊，徐帆江.基于JMS的數(shù)據(jù)推送系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用，2005.

[5]彭珍，曾廣周.基于JMS規(guī)范的群組通信中間件的研究[J].計(jì)算機(jī)工程與設(shè)計(jì)，2005.

[6]張帆.基于JMS的消息中間件的設(shè)計(jì)[D].武漢理工大學(xué)，2007.

[7]戴俊.基于ActiveMQ的異步消息總線的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2010.

[8]李英芳.基于網(wǎng)絡(luò)報(bào)稅系統(tǒng)的消息隊(duì)列中間件的研究與設(shè)計(jì)[D].西安電子科技大學(xué)，2006.