■廣州 張鵬 諶得志

計(jì)算資源是各類應(yīng)用系統(tǒng)完成數(shù)據(jù)信息處理的物質(zhì)基礎(chǔ)。通過有效調(diào)度處理任務(wù)，可以更加充分利用有限的計(jì)算資源，提高信息系統(tǒng)的工作效率。

原有的業(yè)務(wù)系統(tǒng)是由若干臺(tái)服務(wù)器組成的，每臺(tái)服務(wù)器又部署了若干業(yè)務(wù)處理軟件。這些處理軟件獨(dú)立完成從任務(wù)調(diào)度到數(shù)據(jù)處理的全過程。由于新增業(yè)務(wù)越來越多，系統(tǒng)逐漸呈現(xiàn)碎片化的趨勢。業(yè)務(wù)分布依靠人工調(diào)節(jié)，存在部分服務(wù)器資料占用率偏高，而部分服務(wù)器虛耗的現(xiàn)象。

為了改善原有業(yè)務(wù)系統(tǒng)存在的問題，更加有效的利用軟硬件資源，結(jié)合業(yè)務(wù)工作實(shí)際，提出了基于ActiveMQ 數(shù)據(jù)總線的分布式業(yè)務(wù)處理模型。

ActiveMQ 是Apache 軟件基金會(huì)所研發(fā)的開放源代碼消息中間件。它是一個(gè)純java 開發(fā)的軟件，具有良好的跨平臺(tái)特性。ActiveMQ 支持多種語言和協(xié)議，適用于異步調(diào)用、一對多通信、多應(yīng)用解耦以及提高系統(tǒng)伸縮性等用途，在各類系統(tǒng)開發(fā)設(shè)計(jì)中廣泛使用。

將ActiveMQ 應(yīng)用到分布式的業(yè)務(wù)處理平臺(tái)的設(shè)計(jì)過程中，可以通過其消息隊(duì)列功能實(shí)現(xiàn)多臺(tái)數(shù)據(jù)處理終端的協(xié)同工作，并且可以解除任務(wù)調(diào)度和任務(wù)處理的緊密耦合，提高系統(tǒng)的整體性。

設(shè)計(jì)思路

采用ActiveMQ 作為數(shù)據(jù)總線，解決了任務(wù)調(diào)度和多機(jī)系統(tǒng)工作的問題。如圖1 所示，系統(tǒng)分為三部份：數(shù)據(jù)總線、生產(chǎn)者和消費(fèi)者。

數(shù)據(jù)總線由ActiveMQ 實(shí)現(xiàn)，主要承擔(dān)接收任務(wù)調(diào)度信息，協(xié)調(diào)多機(jī)完成任務(wù)處理。生產(chǎn)者由若干觸發(fā)器程序組成。生產(chǎn)者緊貼業(yè)務(wù)需求開發(fā)，負(fù)責(zé)產(chǎn)生任務(wù)調(diào)度信息，向數(shù)據(jù)總線發(fā)出執(zhí)行請求。消費(fèi)者獲取執(zhí)行任務(wù)和參數(shù)，完成最終數(shù)據(jù)處理任務(wù)。

圖1 系統(tǒng)結(jié)構(gòu)圖

為了區(qū)分業(yè)務(wù)優(yōu)先級，數(shù)據(jù)總線由多條隊(duì)列組成，業(yè)務(wù)調(diào)度信息被發(fā)送到不同的隊(duì)列中。再由數(shù)據(jù)總線將消息指派給消費(fèi)者進(jìn)行處理。消費(fèi)者終端可以根據(jù)本地配置決定注冊到哪些消息隊(duì)列來獲取消息。

這樣設(shè)計(jì)的好處是可以為特別的消費(fèi)者單獨(dú)指定消息隊(duì)列，這對于實(shí)時(shí)性要求特別高的或是運(yùn)行環(huán)境有特別要求的業(yè)務(wù)，具有極其重要的意義。

不同業(yè)務(wù)處理的優(yōu)先次序問題也是需要重點(diǎn)考慮的。對于實(shí)時(shí)性要求較高的處理任務(wù)，應(yīng)該處于較高的處理優(yōu)先級，并被盡可能快速的執(zhí)行。而對于一些實(shí)時(shí)性要求不太高的任務(wù)，可以等到系統(tǒng)有空余資源時(shí)再處理。

此外，需要注意一些耗時(shí)較長的數(shù)據(jù)處理任務(wù)，有可能會(huì)大量占用處理資源，使得實(shí)時(shí)性要求較高的業(yè)務(wù)被堵塞在隊(duì)列中，進(jìn)而導(dǎo)致數(shù)據(jù)處理時(shí)延增大，資料時(shí)效性降低。

分布式系統(tǒng)中多個(gè)消費(fèi)者同時(shí)工作可以解決一部分的優(yōu)先次序問題，因?yàn)槎鄠€(gè)消費(fèi)者的存在從某種程度上減少了單個(gè)消費(fèi)者被任務(wù)堵塞的現(xiàn)象。為了進(jìn)一步解決數(shù)據(jù)處理優(yōu)先級問題，消費(fèi)者模塊設(shè)計(jì)采用兩級優(yōu)先級控制機(jī)制，系統(tǒng)模型結(jié)構(gòu)圖如圖2 所示。

圖2 消費(fèi)模塊原理圖

第一級稱為源抑制機(jī)制。系統(tǒng)通過定義不同的ActiveMQ 通信隊(duì)列對業(yè)務(wù)進(jìn)行區(qū)分，消費(fèi)者模塊通過控制是否注冊到ActiveMQ 消息隊(duì)列中。

決定是否接受數(shù)據(jù)總線指派的任務(wù)。它的具體做法是消費(fèi)模塊按照配置初始化監(jiān)聽消息隊(duì)列，并將接收到的調(diào)度信息存儲(chǔ)到優(yōu)先級隊(duì)列中。監(jiān)聽器不斷的檢查優(yōu)先級隊(duì)列，切斷低于最低優(yōu)先級的消息隊(duì)列，直到優(yōu)先級隊(duì)列被清空為止。這樣消費(fèi)者模塊始終只可以接收到更高優(yōu)先級任務(wù)，低優(yōu)先級的任務(wù)會(huì)被指派給其他服務(wù)器或是保留在數(shù)據(jù)總線中，直到有空閑消費(fèi)者注冊到該隊(duì)列時(shí)，任務(wù)才會(huì)被指派給消費(fèi)者執(zhí)行。

第二級就是優(yōu)先級隊(duì)列機(jī)制。消費(fèi)者接收到的消息被保存在一個(gè)優(yōu)先級隊(duì)列中，而優(yōu)先級是由本地監(jiān)聽的隊(duì)列順序來決定的。監(jiān)聽控制模塊按照優(yōu)先級從高到底的順序把消息推送到通信隊(duì)列中。由于監(jiān)聽控制模塊一次只推送一條消息到通信隊(duì)列中，以保證執(zhí)行器獲取的始終是優(yōu)先級隊(duì)列中的最高優(yōu)先級任務(wù)。最后，執(zhí)行器不斷的從通信隊(duì)列中獲取任務(wù)，并指派給工作進(jìn)程來完成處理。

實(shí)現(xiàn)及驗(yàn)證

搭建該系統(tǒng)首先需要部署Apache ActiveMQ 軟件。該軟件配置比較簡單，這里就不詳細(xì)介紹了，具體內(nèi)容可以參考官方網(wǎng)站說明。其次，就是消費(fèi)模塊的實(shí)現(xiàn)。消費(fèi)模塊采用python 語言開發(fā)。python 具備良好的跨平臺(tái)能力，而且是極佳的膠水語言，可以適應(yīng)多種環(huán)境的任務(wù)調(diào)度需求。Python 語言支持通過stomp 協(xié)議訪問ActiveMQ，所以在開發(fā)前需要安裝python 的stomp 庫。

當(dāng) python 完成ActiveMQ 的注冊后，就可以從ActiveMQ 獲取消息了。

需要注意的是收到的消息被保存到queue 模塊的PriorityQueue 隊(duì)列中。監(jiān)聽控制部分通過不斷檢查PriorityQueue 隊(duì)列來確定哪些隊(duì)列會(huì)被注冊（subscribe）或是注銷（unsubscribe）。

除了PriorityQueue 外還需要multiprocessing 模塊的消息隊(duì)列Queue，因?yàn)镼ueue 是進(jìn)程安全的，適合用于監(jiān)聽器和執(zhí)行器之間傳遞消息。

監(jiān)聽器只有在通信隊(duì)列Queue 為空時(shí)，才會(huì)向里推送消息。因?yàn)?，Queue 時(shí)先進(jìn)先出的，當(dāng)多條消息同時(shí)位于通信隊(duì)列Queue 中，可能會(huì)造成任務(wù)優(yōu)先級的混亂。特別是當(dāng)個(gè)別任務(wù)處理耗時(shí)較長時(shí)，對信息處理優(yōu)先級影響尤其明顯。最后由執(zhí)行器從通信隊(duì)列中獲取消息后會(huì)將任務(wù)提交給進(jìn)程池Pool完成處理。

圖3 ActiveMQ 隊(duì)列開放情況

為了驗(yàn)證系統(tǒng)的優(yōu)先級調(diào)度，定義了5 條消息隊(duì)列，分別為channel1 到channel5。先向channel2與channel3 發(fā)送消息，間隔1 秒時(shí)間再向channel1、與channel3 發(fā)送消息。

第一次發(fā)送向channel3的消息被最新消費(fèi)，其次是第二次發(fā)送向channel3的消息被消耗，此時(shí)觀察ActiveMQ 監(jiān)控頁面如圖3 所示。

第二次發(fā)送的channel1的信息被保留在了隊(duì)列中。接下來被消耗的才是第一次發(fā)送的channel2 的信息。最后是channel1 的消息。

經(jīng)過多次測試，系統(tǒng)基本能夠保證多機(jī)系統(tǒng)工作和高優(yōu)先級任務(wù)被優(yōu)先執(zhí)行。

總結(jié)

基于ActiveMQ 的分布式業(yè)務(wù)處理平臺(tái)，依托數(shù)據(jù)總線實(shí)現(xiàn)多機(jī)的協(xié)同工作，是一種相對簡單的分布式數(shù)據(jù)處理的實(shí)現(xiàn)方法，但對于業(yè)務(wù)數(shù)據(jù)處理的效率提高是十分明顯的。采用多機(jī)協(xié)同處理，可以更加有效的利用閑置的處理資源，同時(shí)也可以避免單節(jié)點(diǎn)故障造成的業(yè)務(wù)中斷。對于新增業(yè)務(wù)只需遵守平臺(tái)規(guī)范開發(fā)觸發(fā)器（生產(chǎn)者）和業(yè)務(wù)處理邏輯，即可融入到原有的系統(tǒng)架構(gòu)中，也避免新業(yè)務(wù)、新軟件造成的系統(tǒng)破碎化。

這一模型還有很大的優(yōu)化空間，可以將更加復(fù)雜的控制邏輯引入監(jiān)聽模塊的注冊控制機(jī)制中，讓系統(tǒng)更加智能。一套完善的日志系統(tǒng)更加有利于分析系統(tǒng)資源利用情況，提高系統(tǒng)故障排查效率。