基于ＮＩＯ的高并發網絡服務器模型的研究與設計

王偉平　楊思勤

[摘要]隨著J2EE技術在企業級平臺系統中的廣泛應用,用戶對基于JAVA的網絡服務器程序的性能與擴展性提出更高的要求。圍繞服務器模型中高效NIO實現與高擴展性架構兩方面介紹一個網絡應用服務器模型,結合實際應用環境對這種模型的特點及優越性進行說明,并指出進一步的研究方向。

[關鍵詞]JAVA NIO 業務擴展

中圖分類號:TP3文獻標識碼:A文章編號:1671-7597(2009)0910012-02

一、引言

J2EE是一種利用Java2平臺來簡化企業解決方案的開發、部署和管理相關的復雜問題的體系結構。在保留現存的IT資產,快速開發以及支持異構環境等因素的考慮下,眾多大型企業的企業級應用均采用J2EE技術。在大型的企業架構中,基于客戶/服務器模式所設計的服務器程序由于能為客戶提供一些特定的服務而得到了普遍的應用,這種服務器程序的核心技術是并發技術,服務器需要同時對多個客戶請求提供服務[1],為每個連接的客戶都分配一個線程來處理輸入輸出,其線程與客戶機之比幾乎為1:1,因此,應用服務器易受到大量線程開銷的影響,導致了性能低下又缺乏可伸縮性。為了解決這個問題,java平臺的開發者引入了非阻塞I/O機制(NIO)[2]。NIO與IO包提供的阻塞模型不同,NIO在對一個非阻塞的連接進行操作時,調用會立即返回,而不是掛起等待,這就使得一個線程管理多個連接成為可能,從而使資源使用率得到很大的提升[3]。

在滿足高性能需求同時,企業還要求服務器端平臺能提供可伸縮性來滿足大量的新客戶,為了解決當前企業應用的迫切需求,我們需要一種基于NIO技術的兼顧高效并發與業務擴展兩方面的服務器模型。

二、研究現狀

JDK1.4提供的無阻塞I/O(NIO)有效解決了多線程服務器存在的線程開銷問題,在NIO中使用多線程,主要目的已不是為了應對每個客戶端請求而分配獨立的服務線程,而是通過多線程充分利用多個CPU的處理能力,減少處理時間,達到提高服務能力的目的。許多基于NIO的多線程服務器程序往往直接用基于選擇器(Selector)的Reactor模式實現,這種簡單的事件機制對于較復雜的服務器應用,顯然缺乏擴展性和可維護性,而且缺乏直觀清晰的結構層次[4]。

文獻[4]針對上述問題提出了基于事件回調思想下的NIO多線程服務器,但該服務器設計的運行時Socket分發機制無法正常的對SocketChannel

(套接字通道)進行處理。文獻[4]設計將新接收的客戶端通道放在連接接收線程中進行select,當客戶端有數據到達時,socket被分配給了處理線程。在任意給定時刻最多只能有一個線程對SocketChannel進行讀取和寫入操作[5],而客戶端數據到達時連接接收線程仍然在對SocketChannel進行select,導致了連接接收線程與處理線程對客戶端SocketChannel的訪問發生沖突。本文提出的使用多線程套接字分發機制的改良NIO模型很好地解決上述諸多問題。

在具備清晰的層次與高效的性能的同時,服務器的運算邏輯組織方式是決定服務器擴展性的主要因素。例如一個網絡服務器需要向手持PDA終端提供采集數據處理服務,當出現不同接口協議的PDA終端時,服務器必須對新協議進行支持。在服務器開發設計過程中往往只重視服務器的性能而忽視了服務器的再編程能力,這導致某一種特殊應用的網絡服務器擴展性較低或是擴展難度較大。本文使用改良NIO模型的事件回調機制為接口,以NIO模型的線程池業務數據擴展框架的運行載體,構建了一個網絡應用服務器模型,提供了一個具備高效性與擴展性的服務器開發模型解決方案。

三、多線程套接字分發NIO模型

多線程套接字分發NIO模型是本文網絡服務器架構中的通信層與事件接口層模型,也是數據處理層的基礎,向數據層提供了事件回調接口以及TCP數據發送接口。

(一)模型結構

如圖1所示,NIO模型基本可分為以下模塊:

1.通訊層

客戶端代理(TcpClient/TcpClientPool):Tcp客戶端在服務器端的鏡像,包含了該客戶端鏈路的所有信息,并提供了數據發送的方法?？蛻舳舜碇饕ㄌ捉幼滞ǖ琅c輸入緩沖區,緩沖區大小是應用需求而定。

連接接收器(TcpAcceptor):負責啟動服務器的端口監聽,并且對生成的監聽套接字進行select,接收新連接。

鏈路處理器(TcpProcessor/TcpProessorPool):負責處理已分配的鏈路事件,驅動事件接口進行業務運算。服務器將根據鏈路處理器數量均勻分配客戶端代理,通過實現定義的鏈路處理器池(TcpProessorPool)實現線程池的功能。由于該模型下的高并發服務器所服務的客戶端通訊流量相對比較均勻,因此每一個鏈路處理器將會對該處理器內部的socket套接字通道進行select,處理器之間并不交換客戶端代理。

2.事件層

事件通知器(EventNotifier):向上層應用提供了事件注冊方法,并向底層通訊提供事件驅動的方法,即register/notify模式。事件通知器將保存進行了事件注冊的業務對象,并在事件觸發時以輪詢的方式對事件注冊者的運算進行驅動。

事件適配器接口(EventAdapter):定義了通訊事件觸發接口,包括OnAccepted(連接建立)、OnRead(數據到達)、OnClose(連接關閉)。

(二)數據處理流程

數據的處理流程如圖2所示,客戶端A、B、C向服務器發起連接,詳細步驟如下:

如圖2所示NIO模型數據處理流程分為以下幾個步驟:

1.客戶端向服務器發起連接請求:TcpAcceptor通過select阻塞等待連接到來,當selectedKeys為OP_ACCEPT時進入建立連接的處理流程。

2.在該模型中對于所有新建立的連接都必須給其分配一個客戶端代理以做到端到端的對應。因為連接的關閉與建立是一個相對比較頻繁的操作,因此TcpAcceptor通過向TcpClientPool請求TcpClient以增加對象的再利用率。

3.在獲得了TcpClient后,模塊需要將TcpClient分配給空閑的TcpPr

ocessor,此處采用平均分配的方式,向TcpProcessorPool申請,選擇其管理TcpClient數最少的TcpProcessor。

4.在空閑TcpProcessor注冊TcpClient并指定需要監視事件。

5.TcpProcessor對已注冊的TcpClient進行處理,在數據到達時通過EventNotifer驅動事件的業務處理。

(三)設計原理對比分析

該NIO模型相對于其他基于NIO技術的服務器模型主要優勢在三個方面:

1.在NIO的反射模型[3]中,通過Dispatch的中心事件分發方式,使數據處理必須包含對SocketChannel的處理,這樣的層次將降低擴展性,因為對于一個便于進行二次開發通訊架構應該是讓開發人員無需關心數據是怎么來的。本文中的NIO模型將數據的接收和發送通過事件封裝起來,使數據處理代碼與數據獲取/發送代碼分離,從而提高了系統的擴展性。

2.基于事件回調思想下的NIO多線程[5]中將SocketChannel放置在接收線程中select,這樣的作法使得SocketChannel的select與read在不同線程操作時發生沖突,而導致讀取數據的失敗。因此,本文采用均分的機制將客戶端的SocketChannel的select與read放在同一處理線程中,避免了沖突的發生。

3.文獻[5]中數據的發送采用事件接口onWrite實現,而本文的NIO模型則直接采用又TcpClient提供Send方法的方式,這使得程序設計便于理解。因為數據發送動作是由上層發起的,因此使用事件回調的方式將使操作數增多,層次將更為復雜。

四、數據處理層架構

在有了高效且易于擴展的NIO通訊層框架后,服務器同時需要基于NIO模型之上,便于擴展的數據處理層的架構。在企業應用中存在各式各樣的網關服務器程序,例如游戲服務器,Web服務器,終端服務器等,它們都面向連接的數據處理服務程序,對于一個企業來說程序的可擴展性和維護性是非常重要的,若它們的數據處理層架構均采用統一模式,這將大大增加服務器代碼的可閱讀性,維護性以及擴展性。

基于NIO的面向服務對象的擴展業務模型的基本概念是將業務對象的數據處理獨立化,即每一個業務處理單元的數據處理運算相互獨立,在數據處理過程中具有上下文信息。業務處理單元采用掛載的方式,一個業務處理對象下可以掛載多業務處理單元。業務處理對象通過對消息類型的判斷將接口的消息分發給不同的業務處理單元進行處理。與通訊層不相同的是,業務擴展模型主要提供標準的基礎類或是接口以供擴展,本身并不帶有復雜的處理邏輯。下面從核心業務模塊接口和模塊結構兩方面詳細描述。

(一)核心業務模塊接口定義

命令上下文(CmdContext):在整個單個業務處理過程中記錄具體業務的歷史信息與當前狀態。通過了加入上下文機制可以使同一業務中的不同操作在不同的時間區間完成,實現了業務的異步化。

命令處理單元(CmdHandler/CmdHandlerGather):所有業務處理單元都繼承命令處理單元,CmdHandler包含了標準的上下行數據接口,讓業務處理單元以標準的方式掛載在業務對象上。其中,向上接口表現為指令的處理,而向下接口則是網絡數據的處理。CmdHandler的定時器處理接口(disposeTimeOut)接口還完成了統一的定時器處理,通過該接口實現所有的服務器單元共享定時器時間片與定時器處理線程池。CmdHandlerGather的作用是將服務對象將不同類型的指令或消息路由至指定的CmdHandler。

命令發起者接口(CmdSponsor):主要完成了對指令的路由工作。由于模型采用了Request/Response請求響應模式,因此該模式下的業務處理必然會以響應的方式向通知上層模塊。通過CmdSponsor接口去描述指令發起者使得業務處理可以不再局限于模塊對模塊層面,對于已經編寫好的業務單元可以通過以其他的業務單元為發起者完成整個業務鏈,從而大大增強了代碼的復用性。

(二)核心業務模塊整合

在整合了核心業務模塊后,服務器模型大致可分為:

1.接口模塊:向上層應用平臺提供標準的指令接口,并提供接口消息的發送與接收方法。

2.核心服務管理模塊:業務數據的處理核心。通過繼承統一的接口標準,完成不同業務運算,且服務對象相互獨立。

3.事件接口:包含了事件通知接口與事件驅動接口。

4.通訊服務模塊:基于TCP/IP協議的通訊平臺,向上提供了數據發送接口以及通過事件驅動處理單元。

從圖3中可以看出,事件接口與通訊服務模塊構成了整個基于事件驅動的NIO實現模型,通過線程池驅動核心服務管理模塊中的處理單元。定時器線程也是處理單元的運行載體,因此在不考慮具體接口形式時,處理單元將會出現兩個驅動者。為了保證每一個服務對象的上下文保持一致,服務對象的資源方式是需要進行同步處理的。

五、應用實例

GPS車輛監控是在依托于移動網絡下通過GPS車載終端與服務端建立通訊連接,進而實現車輛的GPS監控。對于一些物流型行業,如郵政,煙草配送等,均是具備了數以萬計的車輛資源,這給GPS系統中的網絡通訊服務器的功能和性能又提出了更高的要求。本文介紹的模型已經成功應用于GPS監控系統的業務領域,在NIO技術高性能的基礎上通過以GPS車載終端為服務對象,向GPS車載提供指令解析以及其他的業務服務功能。

性能方面,基于該模型所開發的網絡通信服務平臺通過了2萬臺GPS終端并發的壓力測試。GPS終端作為GPS數據的通訊器,其數據是以相當穩定的速度向平臺發送,不會因為外界因素產生大的波動,連接處理器的均勻分配管理模式與GPS終端通信流量穩定的性質極其吻合。

業務擴展性方面,在實際GPS產品的通訊協議解析業務的開發過程中,該模型所提供的接口標準使開發人員無需關心平臺除數據處理邏輯以外的其他部分。包括通訊服務模塊,核心服務處理模塊在內的架構模塊都已經達到了完全的通用,對于不同的GPS產品(如珠海天琴、上海飛田、深圳龍翰、蘇州宏原等),GPS業界并沒有一個統一的標準協議,統一的數據處理層框架使程序編寫人員只需要編寫實現業務處理單元中的諸如上行、下行以及定時器等標準接口的具體業務。

六、結束與展望

本文提出了基于NIO技術的多線程套接字分發服務器模型,并在此基礎上構建了一套具有高擴展性的數據處理層架構,從而提供了一個高并發網絡應用服務器開發模型的解決方案。通過實際應用的檢驗該模型在性能以及擴展性方面都有著良好的表現,但該模型在復雜的網絡環境下仍存在一定問題。均勻的連接調度機制并不能很好的適應多變的應用環境,因此根據實際應用環境的其它性能指標對連接調度機制進行自適應調整是該模型的下一步的研究方向。

基金項目:國家自然科學基金(60673164)

參考文獻:

[1]劉仕筠、盛志偉、黃健,Linux環境并發服務器設計技術研究[J].成都信息工程學院學報,2006,21(5):630-634.

[2]王潔,JAVA NIO在Socket通訊中的應用[J].成都信息工程學院學報,2003,18(3):258-261.

[3]姜力,基于Java NIO反應器模式設計與實現[J].大慶師范學院報,2008,28(2):27-30.

[4]黃林榕,基于事件的NIO多線程服務器[DB/OL].http://www.ibm.com/

developer works/cn/java/l-niosvr/.2004.4.1.

[5]Sun Microsystems.Java 2 Platform Standard Edition5.0的API規范[Z].2004.

作者簡介:

王偉平(1969-),女,副教授,主要從事計算機網絡研究。