本發(fā)明涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，特別涉及一種用戶消息發(fā)布方法及系統(tǒng)。

背景技術(shù)：

隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，網(wǎng)絡(luò)變得越來越重要。而隨著用戶數(shù)量的增長，網(wǎng)絡(luò)服務(wù)器的壓力也越來越大。用戶消息的發(fā)布以及對應(yīng)用戶的各種操作都需要通過服務(wù)器完成，大用戶量尤其是瞬時用戶量的增大，給服務(wù)器帶來的巨大的壓力。

為了保證服務(wù)器的順利運作，出現(xiàn)了各種負載均衡的解決方案。負載均衡，英文名稱為Load Balance，其意思就是分?jǐn)偟蕉鄠€操作單元上進行執(zhí)行，例如Web服務(wù)器、FTP服務(wù)器、企業(yè)關(guān)鍵應(yīng)用服務(wù)器和其它關(guān)鍵任務(wù)服務(wù)器等，從而共同完成工作任務(wù)。

軟件負載均衡解決方案是指在一臺或多臺服務(wù)器相應(yīng)的操作系統(tǒng)上安裝一個或多個附加軟件來實現(xiàn)負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優(yōu)點是基于特定環(huán)境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。

軟件解決方案缺點也較多，因為每臺服務(wù)器上安裝額外的軟件運行會消耗系統(tǒng)不定量的資源，越是功能強大的模塊，消耗得越多，所以當(dāng)連接請求特別大的時候，軟件本身會成為服務(wù)器工作成敗的一個關(guān)鍵；軟件可擴展性并不是很好，受到操作系統(tǒng)的限制；由于操作系統(tǒng)本身的Bug，往往會引起安全問題。

硬件負載均衡解決方案是直接在服務(wù)器和外部網(wǎng)絡(luò)間安裝負載均衡設(shè)備，這種設(shè)備通常稱之為負載均衡器，由于專門的設(shè)備完成專門的任務(wù)，獨立于操作系統(tǒng)，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量 管理，可達到最佳的負載均衡需求。

負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設(shè)備中，置于服務(wù)器與Internet鏈接之間，有些則以兩塊網(wǎng)絡(luò)適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到后端服務(wù)器群的內(nèi)部網(wǎng)絡(luò)上。

負載均衡從其應(yīng)用的地理結(jié)構(gòu)上分為本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)，本地負載均衡是指對本地的服務(wù)器群做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網(wǎng)絡(luò)結(jié)構(gòu)的服務(wù)器群間作負載均衡。

本地負載均衡能有效地解決數(shù)據(jù)流量過大、網(wǎng)絡(luò)負荷過重的問題，并且不需花費昂貴開支購置性能卓越的服務(wù)器，充分利用現(xiàn)有設(shè)備，避免服務(wù)器單點故障造成數(shù)據(jù)流量的損失。其有靈活多樣的均衡策略把數(shù)據(jù)流量合理地分配給服務(wù)器群內(nèi)的服務(wù)器共同負擔(dān)。即使是再給現(xiàn)有服務(wù)器擴充升級，也只是簡單地增加一個新的服務(wù)器到服務(wù)群中，而不需改變現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)、停止現(xiàn)有的服務(wù)。

全局負載均衡主要用于在一個多區(qū)域擁有自己服務(wù)器的站點，為了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的服務(wù)器，從而獲得最快的訪問速度，也可用于子公司分散站點分布廣的大公司通過Intranet(企業(yè)內(nèi)部互聯(lián)網(wǎng))來達到資源統(tǒng)一合理分配的目的。

負載均衡有三種部署方式：路由模式、橋接模式、服務(wù)直接返回模式。

路由模式部署靈活，約60％的用戶采用這種方式部署；橋接模式不改變現(xiàn)有的網(wǎng)絡(luò)架構(gòu)；服務(wù)直接返回(DSR)比較適合吞吐量大特別是內(nèi)容分發(fā)的網(wǎng)絡(luò)應(yīng)用。約30％的用戶采用這種模式。

現(xiàn)有技術(shù)中，各種負載均衡方案均可以解決負載均衡的問題，但是，效果不一而足。同時，針對具體應(yīng)用環(huán)境而產(chǎn)生的負載均衡機制目前均有不完善之處。尤其是對于用戶服務(wù)器之間的負載均衡問題，目前大多采用輪詢的方式進 行，尚沒有一種可以有效解決負載均衡問題，同時又能夠提高效率，不會對現(xiàn)有網(wǎng)絡(luò)造成很大改變的方案。

技術(shù)實現(xiàn)要素：

本發(fā)明提供一種用戶消息發(fā)布方法及系統(tǒng)，用以解決現(xiàn)有技術(shù)中用戶消息發(fā)布負載均衡的問題。

本發(fā)明提供一種用戶消息發(fā)布方法，包括：

發(fā)布服務(wù)器將發(fā)布消息發(fā)布到消息隊列；

用戶服務(wù)器監(jiān)聽所述消息隊列；

用戶服務(wù)器將監(jiān)聽到的發(fā)布消息在自身所屬用戶中發(fā)布。

所述方法還包括：

所述用戶服務(wù)器通過web socket協(xié)議連接到所述發(fā)布服務(wù)器。

所述方法還包括：

所述用戶服務(wù)器將監(jiān)聽到的發(fā)布消息保存到本地，并在自身所屬用戶中廣播。

所述方法還包括：

所述用戶服務(wù)器監(jiān)聽所述消息隊列，若監(jiān)聽到發(fā)送給自身所屬用戶的發(fā)布消息，則將所述發(fā)布消息發(fā)送對應(yīng)用戶；否則，不作處理。

所述方法還包括：

所述消息隊列中按照先入先出的原則順序排列需要發(fā)布的發(fā)布消息。

所述方法還包括：

所述用戶分別接入對應(yīng)的用戶服務(wù)器，并從所述用戶服務(wù)器獲取所述發(fā)布消息。

一種用戶消息發(fā)布系統(tǒng)，包括：

發(fā)布服務(wù)器，用于將發(fā)布消息發(fā)布到消息隊列；

用戶服務(wù)器，用于監(jiān)聽所述消息隊列；并將監(jiān)聽到的發(fā)布消息在自身所屬 用戶中發(fā)布。

所述發(fā)布服務(wù)器包括消息隊列，用于按照先入先出的原則順序排列需要發(fā)布的發(fā)布消息。

所述用戶服務(wù)器通過web socket協(xié)議連接到所述發(fā)布服務(wù)器。

所述系統(tǒng)還包括用戶終端，用于分別接入對應(yīng)的用戶服務(wù)器，并從所述用戶服務(wù)器獲取所述發(fā)布消息。

本發(fā)明實施例中，通過發(fā)布服務(wù)器將發(fā)布消息發(fā)布到消息隊列；用戶服務(wù)器監(jiān)聽所述消息隊列；用戶服務(wù)器將監(jiān)聽到的發(fā)布消息在自身所屬用戶中發(fā)布。本發(fā)明實施例的方案，能夠在用戶消息發(fā)布時候，發(fā)布服務(wù)器進行消息隊列的發(fā)布，各用戶服務(wù)器通過監(jiān)聽消息隊列獲取對應(yīng)的發(fā)布消息，從而發(fā)布給自身所屬的用戶，提高了用戶消息發(fā)布的效率，同時，在各個用戶服務(wù)器之間實現(xiàn)了負載均衡配置，不會造成網(wǎng)絡(luò)擁堵，降低了系統(tǒng)負擔(dān)，極大的提高了用戶體驗度。

本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在所寫的說明書、權(quán)利要求書、以及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。

下面通過附圖和實施例，對本發(fā)明的技術(shù)方案做進一步的詳細描述。

附圖說明

附圖用來提供對本發(fā)明的進一步理解，并且構(gòu)成說明書的一部分，與本發(fā)明的實施例一起用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的限制。在附圖中：

圖1為本發(fā)明實施例1提供的一種用戶消息發(fā)布方法原理流程圖；

圖2為本發(fā)明實施例2提供的一種用戶消息發(fā)布系統(tǒng)結(jié)構(gòu)示意圖。

具體實施方式

以下結(jié)合附圖對本發(fā)明的優(yōu)選實施例進行說明，應(yīng)當(dāng)理解，此處所描述的優(yōu)選實施例僅用于說明和解釋本發(fā)明，并不用于限定本發(fā)明。

如圖1所示，為本發(fā)明實施例1提供的一種用戶消息發(fā)布方法原理流程圖，其中，

步驟11，發(fā)布服務(wù)器將發(fā)布消息發(fā)布到消息隊列。

發(fā)布服務(wù)器實際上是一臺或者一組服務(wù)器，用以發(fā)布需要針對用戶的消息。這些消息可以是針對某一用戶的，也可以是針對多個或者全部用戶的。發(fā)布服務(wù)器僅完成消息的發(fā)布，并不直接連接用戶。

發(fā)布服務(wù)器獲得需要發(fā)布的消息后，需要將該發(fā)布消息發(fā)布到消息隊列。消息隊列是一個特定的分組，可以按照堆棧的原理進行先入先出的消息順序排列，也可以是根據(jù)其他方式進行消息排列。消息隊列的作用就在于將發(fā)布消息進行排列，或者也可以存儲發(fā)布消息本身。

“消息隊列”是在消息的傳輸過程中保存消息的容器。消息被發(fā)送到隊列中?！跋㈥犃小笔窃谙⒌膫鬏斶^程中保存消息的容器。消息隊列管理器在將消息從它的源中繼到它的目標(biāo)時充當(dāng)中間人。隊列的主要目的是提供路由并保證消息的傳遞；如果發(fā)送消息時接收者不可用，消息隊列會保留消息，直到可以成功地傳遞它。

“消息隊列”是一種消息處理技術(shù)，它為任何應(yīng)用程序提供消息處理和消息隊列功能，無論這些計算機是否在同一個網(wǎng)絡(luò)上或者是否同時聯(lián)機。

“消息隊列網(wǎng)絡(luò)”是能夠相互間來回發(fā)送消息的任何一組計算機。網(wǎng)絡(luò)中的不同計算機在確保消息順利處理的過程中扮演不同的角色。它們中有些提供路由信息以確定如何發(fā)送消息，有些保存整個網(wǎng)絡(luò)的重要信息，而有些只是發(fā)送和接收消息。

“消息隊列”安裝期間，管理員確定哪些服務(wù)器可以互相通信，并設(shè)置特定服務(wù)器的特殊角色。構(gòu)成此“消息隊列”網(wǎng)絡(luò)的計算機稱為“站點”，它們之間通 過“站點鏈接”相互連接。每個站點鏈接都有一個關(guān)聯(lián)的“開銷”，它由管理員確定，指示了經(jīng)過此站點鏈接傳遞消息的頻率。

消息隊列就是一個消息的鏈表。可以把消息看作一個記錄，具有特定的格式以及特定的優(yōu)先級。對消息隊列有寫權(quán)限的進程可以向消息隊列中按照一定的規(guī)則添加新消息；對消息隊列有讀權(quán)限的進程則可以從消息隊列中讀走消息。消息隊列是隨內(nèi)核持續(xù)的。

現(xiàn)有技術(shù)中，主要有兩種類型的消息隊列：POSIX消息隊列以及系統(tǒng)V消息隊列，系統(tǒng)V消息隊列目前被大量使用。考慮到程序的可移植性，新開發(fā)的應(yīng)用程序應(yīng)盡量使用POSIX消息隊列。本實施例對消息隊列的形式不做限定。

系統(tǒng)V消息隊列是隨內(nèi)核持續(xù)的，只有在內(nèi)核重起或者顯示刪除一個消息隊列時，該消息隊列才會真正被刪除。因此系統(tǒng)中記錄消息隊列的數(shù)據(jù)結(jié)構(gòu)(struct ipc_ids msg_ids)位于內(nèi)核中，系統(tǒng)中的所有消息隊列都可以在結(jié)構(gòu)msg_ids中找到訪問入口。消息隊列就是一個消息的鏈表。每個消息隊列都有一個隊列頭，用結(jié)構(gòu)struct msg_queue來描述。隊列頭中包含了該消息隊列的大量信息，包括消息隊列鍵值、用戶ID、組ID、消息隊列中消息數(shù)目等等，甚至記錄了最近對消息隊列讀寫進程的ID。讀者可以訪問這些信息，也可以設(shè)置其中的某些信息。

“消息隊列”管理員還在網(wǎng)絡(luò)中設(shè)置一臺或多臺作為“路由服務(wù)器”的計算機。路由服務(wù)器查看各站點鏈接的開銷，確定經(jīng)過多個站點傳遞消息的最快和最有效的方法，以此決定如何傳遞消息。

步驟12，用戶服務(wù)器監(jiān)聽所述消息隊列。

用戶服務(wù)器是與用戶終端建立直接連接的服務(wù)器，其不僅要直接連接用戶終端，處理用戶終端的消息，同時，為了及時發(fā)布用戶消息，還需要監(jiān)聽消息隊列。

通常，用戶服務(wù)器通過web socket協(xié)議連接到發(fā)布服務(wù)器。WebSocket protocol是HTML5一種新的協(xié)議。它實現(xiàn)了瀏覽器與服務(wù)器全雙工通信(full-duplex)。

在瀏覽器中通過http僅能實現(xiàn)單向的通信,comet可以一定程度上模擬雙向通信,但效率較低,并需要服務(wù)器有較好的支持；flash中的socket和xmlsocket可以實現(xiàn)真正的雙向通信,通過flex ajax bridge,可以在javascript中使用這兩項功能.可以預(yù)見,如果websocket一旦在瀏覽器中得到實現(xiàn),將會替代上面兩項技術(shù),得到廣泛的使用.面對這種狀況，HTML5定義了WebSocket協(xié)議，能更好的節(jié)省服務(wù)器資源和帶寬并達到實時通訊。

現(xiàn)有技術(shù)中，為了實現(xiàn)即時通訊，所用的技術(shù)都是輪詢(polling)。輪詢是在特定的的時間間隔(如每1秒)，由瀏覽器對服務(wù)器發(fā)出HTTP request，然后由服務(wù)器返回最新的數(shù)據(jù)給客服端的瀏覽器。這種傳統(tǒng)的HTTP request的模式帶來很明顯的缺點–瀏覽器需要不斷的向服務(wù)器發(fā)出請求，然而HTTP request的header是非常長的，里面包含的有用數(shù)據(jù)可能只是一個很小的值，這樣會占用很多的帶寬。而比較新的技術(shù)去做輪詢的效果是Comet–用了AJAX。但這種技術(shù)雖然可達到全雙工通信，但依然需要發(fā)出請求。

HTML5 WebSocket設(shè)計出來的目的就是要取代輪詢和Comet技術(shù)，使客戶端瀏覽器具備像C/S架構(gòu)下桌面系統(tǒng)的實時通訊能力。瀏覽器通過JavaScript向服務(wù)器發(fā)出建立WebSocket連接的請求，連接建立以后，客戶端和服務(wù)器端就可以通過TCP連接直接交換數(shù)據(jù)。因為WebSocket連接本質(zhì)上就是一個TCP連接，所以在數(shù)據(jù)傳輸?shù)姆€(wěn)定性和數(shù)據(jù)傳輸量的大小方面，和輪詢以及Comet技術(shù)比較，具有很大的性能優(yōu)勢。

在WebSocket API，瀏覽器和服務(wù)器只需要要做一個握手的動作，然后，瀏覽器和服務(wù)器之間就形成了一條快速通道。兩者之間就直接可以數(shù)據(jù)互相傳送。在實現(xiàn)websocket連線過程中，需要通過瀏覽器發(fā)出websocket連線請求，然后服務(wù)器發(fā)出回應(yīng)，這個過程通常稱為“握手”(handshaking)。

WebSocket協(xié)議本質(zhì)上是一個基于TCP的協(xié)議。為了建立一個 WebSocket連接，客戶端瀏覽器首先要向服務(wù)器發(fā)起一個HTTP請求，這個請求和通常的HTTP請求不同，包含了一些附加頭信息，其中附加頭信息”Upgrade:WebSocket”表明這是一個申請協(xié)議升級的HTTP請求，服務(wù)器端解析這些附加的頭信息然后產(chǎn)生應(yīng)答信息返回給客戶端，客戶端和服務(wù)器端的WebSocket連接就建立起來了，雙方就可以通過這個連接通道自由的傳遞信息，并且這個連接會持續(xù)存在直到客戶端或者服務(wù)器端的某一方主動的關(guān)閉連接。

特別的，用戶服務(wù)器將監(jiān)聽到的發(fā)布消息可以保存到本地，并在自身所屬用戶中廣播。

步驟13，用戶服務(wù)器將監(jiān)聽到的發(fā)布消息在自身所屬用戶中發(fā)布。

用戶服務(wù)器監(jiān)聽到發(fā)布服務(wù)器發(fā)布到消息隊列中的發(fā)布消息后，獲取該消息，可以保存到本地，或者不作保存。用戶服務(wù)器監(jiān)聽所述消息隊列，若監(jiān)聽到發(fā)送給自身所屬用戶的發(fā)布消息，則將所述發(fā)布消息發(fā)送對應(yīng)用戶；否則，不作處理。

用戶分別接入對應(yīng)的用戶服務(wù)器，并從所述用戶服務(wù)器獲取所述發(fā)布消息。用戶與用戶服務(wù)器之間的對應(yīng)，通?？梢允歉鶕?jù)地域就近原則或者地址就近原則，所有的用戶均有針對的用戶服務(wù)器。

本發(fā)明實施例中，通過發(fā)布服務(wù)器將發(fā)布消息發(fā)布到消息隊列；用戶服務(wù)器監(jiān)聽所述消息隊列；用戶服務(wù)器將監(jiān)聽到的發(fā)布消息在自身所屬用戶中發(fā)布。本發(fā)明實施例的方案，能夠在用戶消息發(fā)布時候，發(fā)布服務(wù)器進行消息隊列的發(fā)布，各用戶服務(wù)器通過監(jiān)聽消息隊列獲取對應(yīng)的發(fā)布消息，從而發(fā)布給自身所屬的用戶，提高了用戶消息發(fā)布的效率，同時，在各個用戶服務(wù)器之間實現(xiàn)了負載均衡配置，不會造成網(wǎng)絡(luò)擁堵，降低了系統(tǒng)負擔(dān)，極大的提高了用戶體驗度。

如圖2所示，為本發(fā)明實施例2提供的一種用戶消息發(fā)布系統(tǒng)結(jié)構(gòu)示意圖， 其中，

發(fā)布服務(wù)器21，用于將發(fā)布消息發(fā)布到消息隊列；

用戶服務(wù)器22，用于監(jiān)聽所述消息隊列；并將監(jiān)聽到的發(fā)布消息在自身所屬用戶中發(fā)布。

特別的，上述發(fā)布服務(wù)器21包括消息隊列，用于按照先入先出的原則順序排列需要發(fā)布的發(fā)布消息。

特別的，上述用戶服務(wù)器22通過web socket協(xié)議連接到發(fā)布服務(wù)器21。

特別的，上述系統(tǒng)還包括用戶終端23，用于分別接入對應(yīng)的用戶服務(wù)器22，并從所述用戶服務(wù)器22獲取所述發(fā)布消息。

綜上所述，本發(fā)明實施例中，通過發(fā)布服務(wù)器將發(fā)布消息發(fā)布到消息隊列；用戶服務(wù)器監(jiān)聽所述消息隊列；用戶服務(wù)器將監(jiān)聽到的發(fā)布消息在自身所屬用戶中發(fā)布。本發(fā)明實施例的方案，能夠在用戶消息發(fā)布時候，發(fā)布服務(wù)器進行消息隊列的發(fā)布，各用戶服務(wù)器通過監(jiān)聽消息隊列獲取對應(yīng)的發(fā)布消息，從而發(fā)布給自身所屬的用戶，提高了用戶消息發(fā)布的效率，同時，在各個用戶服務(wù)器之間實現(xiàn)了負載均衡配置，不會造成網(wǎng)絡(luò)擁堵，降低了系統(tǒng)負擔(dān)，極大的提高了用戶體驗度。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計算機程序產(chǎn)品。因此，本發(fā)明可采用完全硬件實施例、完全軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器和光學(xué)存儲器等)上實施的計算機程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備(系統(tǒng))、和計算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入 式處理機或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導(dǎo)計算機或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計算機或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。