王子光 王子明
摘 要:隨著面向服務架構的大規(guī)模分布式系統(tǒng)的應用,多個系統(tǒng)之間由于數(shù)據(jù)集成的需要,彼此間要高并發(fā)傳遞大量數(shù)據(jù),特別是狀態(tài)數(shù)據(jù)的同步,對數(shù)據(jù)的實時性要求越來越高。數(shù)據(jù)單純通過客戶端以Pull(拉取)模式獲取已經(jīng)不能滿足實時性要求,高頻率服務調用也會給服務端數(shù)據(jù)庫帶來較大的壓力。單純通過服務端以Push(推送)模式推送給客戶端也不能滿足客戶端對個性化數(shù)據(jù)的需求,大量推送既會給服務端帶來較大壓力,又會造成客戶端數(shù)據(jù)處理不及時。本文針對高并發(fā)數(shù)據(jù)共享系統(tǒng)應用過程中產(chǎn)生的性能問題,提出一種基于pub/sub消息處理的Push-Pull混合模式優(yōu)化方案,實踐表明該方案極大地提高了系統(tǒng)可用性及數(shù)據(jù)安全性,對同類系統(tǒng)的性能優(yōu)化具有較好的借鑒作用。
關鍵詞:高并發(fā);數(shù)據(jù)共享系統(tǒng);性能優(yōu)化;pub/sub消息處理;Push-Pull混合模式
中圖分類號:TN929.5 文獻標識碼:A 文章編號:2096-4706(2018)04-0065-03
Abstract:With the application of large-scale distributed systems based on service oriented architecture,due to the need of data integration between multiple systems,these systems transfer large amounts of data between each other,especially the synchronous state of the data. The data obtained by the client through pull mode cannot meet the real-time requirements,high-frequent service-calls have also bring greater pressure to the database server through push mode;only by the server through the push mode to the client,it cannot meet the needs of personalized data,also a large number of push will bring greater pressure on both server and client which cannot cause data processing timely. In this paper,with the performance problems in the application of the high-concurrent data sharing system,it put forward a kind of Push-Pull mixed mode optimization scheme based on pub/sub message processing,the practice shows that the scheme greatly improves the system availability and data security,also provides a good reference for optimizing the performance of similar systems.
Keywords:high concurrency;data sharing system;performance optimization;pub/sub processing;push-pull mixed mode
0 引 言
目前,面向服務架構的大規(guī)模分布式系統(tǒng)之間的數(shù)據(jù)共享和集成已經(jīng)成為越來越重要的研究問題。傳統(tǒng)的系統(tǒng)間數(shù)據(jù)共享和集成多采用Push或Pull兩種方式。Push方式多采用消息推送模式,即由服務端將數(shù)據(jù)推送給客戶端,但推送數(shù)據(jù)信息過多就不能滿足客戶端的個性化數(shù)據(jù)需求。Pull方式多采用Webservice服務方式,即客戶端通過主動調用服務端開放的服務接口獲取數(shù)據(jù),但由于Webservice服務存在網(wǎng)絡傳輸不穩(wěn)定以及開銷較大的弊端,因此在高并發(fā)系統(tǒng)中進行數(shù)據(jù)共享會存在性能問題。本文設計并實現(xiàn)了一種Push-Pull混合模式優(yōu)化方案,服務端通過pub/sub消息處理機制向多客戶端推送“微數(shù)據(jù)”,客戶端根據(jù)這些數(shù)據(jù)判斷調用服務接口的時機,以獲取其他個性化數(shù)據(jù),較好地解決了高并發(fā)數(shù)據(jù)共享系統(tǒng)中存在的實際性能問題。
1 Push-Pull模式介紹
推送(Push)技術是根據(jù)用戶喜好,有目的、有選擇性地定期將用戶感興趣的信息主動發(fā)送到用戶可查看的設備上。Push技術的主要優(yōu)點在于及時性,能夠方便地向用戶“推送”不斷更新的動態(tài)信息,且對用戶專業(yè)性要求低。拉取(Pull)技術指用戶主動發(fā)起請求,傳統(tǒng)意義上的拉取是指用戶有目的地在網(wǎng)絡上主動查詢信息,用戶通過瀏覽器發(fā)送請求,由Web獲取所需信息,并返回給用戶。面對擁有海量信息的Internet環(huán)境,搜索引擎是較為有效的網(wǎng)絡信息“拉取”(查詢)的檢索工具[1]。Web應用系統(tǒng)之間的數(shù)據(jù)拉取通常是指客戶端主動調用服務端的服務接口或其他應用接口來獲取數(shù)據(jù),以達到數(shù)據(jù)共享的目的。
Push技術主要優(yōu)點在于實時性,客戶端無需額外保存狀態(tài),缺點是不能保證推送信息一定能夠發(fā)送成功,推送量過大會給服務端造成性能壓力。另外,推送數(shù)據(jù)也缺乏個性化定制。Pull技術的主要優(yōu)點是客戶端主動拉取數(shù)據(jù),針對性較強,能滿足個性化需求,且網(wǎng)絡上所傳輸?shù)臄?shù)據(jù)量較少,方便服務端和客戶端通信,但缺點是實時性較差,客戶端無效請求較多,對客戶端的要求較高[2]。
2 面向服務架構的高并發(fā)數(shù)據(jù)共享系統(tǒng)的性能問題
高并發(fā)數(shù)據(jù)共享系統(tǒng)保存著企業(yè)可共享的核心業(yè)務數(shù)據(jù),外圍系統(tǒng)只能通過共享系統(tǒng)獲取業(yè)務數(shù)據(jù),核心業(yè)務數(shù)據(jù)量龐大且更新頻繁。共享系統(tǒng)通過ESB向外圍系統(tǒng)提供多種數(shù)據(jù)查詢服務(Webservice),外圍系統(tǒng)通過調用查詢服務獲取數(shù)據(jù),達到數(shù)據(jù)共享的目的,此種Pull模式外圍系統(tǒng)是被動的,并嚴重依賴服務質量及網(wǎng)絡穩(wěn)定性,而且客戶端為了獲取數(shù)據(jù)可能會多次調用不同的服務接口,大大增加了客戶端的運行開銷,也會由于客戶端的高并發(fā)調用造成服務端數(shù)據(jù)庫的巨大壓力,比如外圍系統(tǒng)需要經(jīng)常獲取核心業(yè)務數(shù)據(jù)“狀態(tài)”信息。在Pull模式下,外圍系統(tǒng)常會使用“輪詢”方式,雖然這種方式設計較為簡單,外圍系統(tǒng)只需通過定時啟動輪詢服務來獲取服務端的狀態(tài)數(shù)據(jù),但是“輪詢”效果卻不甚理想。一是狀態(tài)信息強調時效性,輪詢頻率設置過高,會造成服務端數(shù)據(jù)庫壓力增大,客戶端獲取數(shù)據(jù)延遲;二是輪詢頻率設置過低,會造成獲取狀態(tài)信息延遲過大,失去數(shù)據(jù)價值;三是狀態(tài)信息未更新,輪詢?nèi)匀粏樱斐伞翱辙D”現(xiàn)象。
Pull數(shù)據(jù)共享模式如圖1所示。
為了解決上述問題,可以設計一種Push處理模式,將數(shù)據(jù)共享系統(tǒng)的核心業(yè)務數(shù)據(jù)通過消息中間件(MOM),如開源的ActiveMQ、RabbitMQ等,并以Pub/Sub模式主動向客戶端推送數(shù)據(jù)。由數(shù)據(jù)共享系統(tǒng)發(fā)布主題,客戶端訂閱感興趣的主題,ESB服務總線進行消息轉發(fā)并記錄消息日志。
這種發(fā)布訂閱處理方式減少了客戶端的調用開銷,但推送數(shù)據(jù)量過大仍會給服務端造成較大壓力。另外,還可能不滿足客戶端的個性化數(shù)據(jù)需求,推送的很多數(shù)據(jù)客戶端沒有使用,反而會增加調用接口的次數(shù)。Push數(shù)據(jù)共享模式如圖2所示。
3 基于Pub/Sub消息處理的Push-Pull混合模式優(yōu)化方案
為了結合Push和Pull兩種消息處理模式的優(yōu)勢,解決在高并發(fā)數(shù)據(jù)共享系統(tǒng)中出現(xiàn)的性能問題,這里提出一種基于消息中間件的Pub/Sub模式的Push-Pull混合模式優(yōu)化方案,如圖3所示。
首先,服務端與客戶端通過Pub/Sub消息模式進行多主題消息推送與接收。Push模式的關鍵是需要設計好推送給客戶端的“微數(shù)據(jù)”。“微數(shù)據(jù)”是指多個客戶端需要的“公共數(shù)據(jù)”。“公共數(shù)據(jù)”推送量需要適度,既不能太多,也不能太少,還需考慮客戶端的消費能力。太多會造成服務端推送壓力大,速度慢,而客戶端消費有限;太少又會過多依賴拉取數(shù)據(jù),數(shù)據(jù)延遲較大,且對服務端仍會造成一定壓力。“微數(shù)據(jù)”的設計應盡量滿足客戶端對業(yè)務維度基本公共數(shù)據(jù)的要求。
客戶端對推送數(shù)據(jù)的消費能力也是需要解決的重要問題。如果客戶端的處理邏輯復雜,可能會造成消息堆積,為了解決此問題,可將服務端推送過來的數(shù)據(jù)不加處理,先行存入客戶端臨時數(shù)據(jù)庫表中,客戶端自身啟動定時調度任務,選取本地數(shù)據(jù)進行處理,同時為了保持數(shù)據(jù)時效性,可將定時調度頻率適當縮短。
另外,在滿足多客戶端基本公共數(shù)據(jù)要求的情況下,依靠服務調用的Pull模式獲取其他個性化數(shù)據(jù)。比如當客戶端獲取業(yè)務狀態(tài)等公共數(shù)據(jù)后,可根據(jù)當前狀態(tài)適時調用服務端提供的服務接口來獲取其他業(yè)務數(shù)據(jù)。
4 測試結果
保險業(yè)務狀態(tài)查詢系統(tǒng)(IQS)是保險核心數(shù)據(jù)共享系統(tǒng)(CBS)的某一外圍系統(tǒng),通過與CBS的交互來獲取保險業(yè)務狀態(tài)的最新信息。這里兩個系統(tǒng)數(shù)據(jù)交互采用基于Push-Pull混合模式的異步處理交易方式,IQS系統(tǒng)通過ESB和Active MQ與CBS進行集成,這里ESB選用開源的Mule平臺,集成方式如圖4所示。
CBS設置新契約狀態(tài)變化、保全狀態(tài)變化、理賠狀態(tài)變化等11個主題,IQS系統(tǒng)進行持久性訂閱來獲取狀態(tài)信息。CBS在核心業(yè)務數(shù)據(jù)庫表中,如新契約表(T_POLICY)、保全表(T_POLICY_CHANGE)等主表增加tirgger,核心業(yè)務數(shù)據(jù)狀態(tài)變化后,自動觸發(fā)向CBS中的待通知表(T_BUSI_NOTIFY)插入數(shù)據(jù),然后啟動Quartz定時任務,每5秒推送待通知表中數(shù)據(jù)給Mule并轉發(fā)給IQS,IQS成功接收后,將數(shù)據(jù)轉移至已通知表(T_BUSI_NOTIFIED)。
Push-Pull混合模式優(yōu)化方案新契約主題“公共數(shù)據(jù)”設計如表1所示。
對11個主題中的每個主題進行10萬數(shù)據(jù)壓力測試,總量達到百萬。以數(shù)據(jù)量最大的新契約主題為例,測試結果如表2所示。
通過測試可以看到,混合模式的“公共數(shù)據(jù)”設計好后,除了少量個性化數(shù)據(jù)需求不能滿足客戶端需要接口調用外,調用次數(shù)大大減少,處理速度也比其他兩種處理方式提高了很多。
5 結 論
將此Push-Pull混合模式的性能優(yōu)化方案應用于高并發(fā)數(shù)據(jù)共享系統(tǒng),公共“微數(shù)據(jù)”的推送基本滿足了多客戶端的一般性需求,其他個性化數(shù)據(jù)只需較少地調用服務接口即可滿足,減少了資源消耗,大大減輕了服務端和客戶端的壓力,取得了較好應用效果。
參考文獻:
[1] CSDN.消息系統(tǒng)該Push/Pull模式分析 [EB/OL].https://blog.csdn.net/pi9nc/article/details/27714745,2014-05-30.
[2] 索傳軍.Push技術開發(fā)應用研究述評 [J].現(xiàn)代圖書情報技術,2003(3):48-50+63.
作者簡介:王子光(1984-),男,河南人,碩士。研究方向:軟件工程、軟件技術在企業(yè)應用;王子明(1984-),男,河南人,工程師,碩士。研究方向:軟件工程、軟件開發(fā)技術。