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

背景技術(shù)：

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

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

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

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

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

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

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

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

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

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

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

現(xiàn)有技術(shù)中，各種負載均衡方案均可以解決負載均衡的問題，但是，效果不一而足。同時，針對具體應用環(huán)境而產(chǎn)生的負載均衡機制目前均有不完善之處。尤其是對于用戶服務器之間的負載均衡問題，當頁面數(shù)據(jù)發(fā)布時候，大多 是發(fā)布到一臺服務器上，其它服務器在需要獲取該頁面數(shù)據(jù)時，再從該服務器上獲取。這種方案效率較低，同時容易出現(xiàn)擁塞，亟需要一種頁面數(shù)據(jù)的發(fā)布方案以有效避免服務器層面的擁塞。

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

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

本發(fā)明提供一種頁面數(shù)據(jù)發(fā)布方法，包括：

發(fā)布服務器將發(fā)布消息發(fā)布到發(fā)布信道；

用戶服務器監(jiān)聽所述發(fā)布信道；

用戶服務器根據(jù)監(jiān)聽到的發(fā)布消息將對應的發(fā)布內(nèi)容同步到本地。

所述方法還包括：

所述發(fā)布服務器通過redis內(nèi)存數(shù)據(jù)庫發(fā)布系統(tǒng)進行發(fā)布。

所述方法還包括：

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

所述方法還包括：

所述用戶服務器監(jiān)聽所述發(fā)布信道，若監(jiān)聽到發(fā)送給自身的發(fā)布消息，則將所述發(fā)布消息對應的發(fā)布內(nèi)容同步到本地；否則，不作處理。

所述方法還包括：

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

所述方法還包括：

用戶訪問頁面數(shù)據(jù)時，在對應的用戶服務器獲取相應內(nèi)容。

所述方法還包括：

若所述用戶不能從對應的用戶服務器獲取所述頁面數(shù)據(jù)，則由所述用戶服務器進行回源操作，到其它用戶服務器獲取相應頁面數(shù)據(jù)，并存儲到自身用戶 服務器。

一種頁面數(shù)據(jù)發(fā)布系統(tǒng)，包括：

發(fā)布服務器，用于將發(fā)布消息發(fā)布到發(fā)布信道；

用戶服務器，用于監(jiān)聽所述發(fā)布信道；并根據(jù)監(jiān)聽到的發(fā)布消息將對應的發(fā)布內(nèi)容同步到本地。

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

所述發(fā)布服務器通過redis內(nèi)存數(shù)據(jù)庫發(fā)布系統(tǒng)進行發(fā)布。

所述系統(tǒng)還包括用戶終端，用于分別接入對應的用戶服務器，并從所述用戶服務器獲取頁面數(shù)據(jù)；若無法獲取，則由所述用戶服務器進行回源操作，到其它用戶服務器獲取相應頁面數(shù)據(jù)，并存儲到自身用戶服務器。

本發(fā)明實施例中，通過發(fā)布服務器將發(fā)布消息發(fā)布到發(fā)布信道；用戶服務器監(jiān)聽所述發(fā)布信道；用戶服務器根據(jù)監(jiān)聽到的發(fā)布消息將對應的發(fā)布內(nèi)容同步到本地。本發(fā)明實施例的方案，能夠在頁面數(shù)據(jù)發(fā)布時候，發(fā)布服務器進行發(fā)布信道的發(fā)布，各用戶服務器通過監(jiān)聽發(fā)布信道獲取對應的發(fā)布消息，從而本村到本地，同時在各個用戶服務器進行了頁面數(shù)據(jù)的發(fā)布，提高了頁面數(shù)據(jù)發(fā)布的效率。同時，在各個用戶服務器之間實現(xiàn)了負載均衡配置，不會造成網(wǎng)絡擁堵，降低了系統(tǒng)負擔，極大的提高了用戶體驗度。

本發(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提供的一種頁面數(shù)據(jù)發(fā)布方法原理流程圖；

圖2為本發(fā)明實施例2提供的一種頁面數(shù)據(jù)發(fā)布系統(tǒng)結(jié)構(gòu)示意圖。

具體實施方式

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

如圖1所示，為本發(fā)明實施例1提供的一種頁面數(shù)據(jù)發(fā)布方法原理流程圖，其中，

步驟11，發(fā)布服務器將發(fā)布消息發(fā)布到發(fā)布信道。

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

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

“發(fā)布信道”是在消息的傳輸過程中保存消息的容器。消息被發(fā)送到隊列中。“發(fā)布信道”是在消息的傳輸過程中保存消息的容器。發(fā)布信道管理器在將消息從它的源中繼到它的目標時充當中間人。隊列的主要目的是提供路由并保證消息的傳遞；如果發(fā)送消息時接收者不可用，發(fā)布信道會保留消息，直到可以成功地傳遞它。

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

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

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

發(fā)布信道就是一個消息的鏈表?？梢园严⒖醋饕粋€記錄，具有特定的格式以及特定的優(yōu)先級。對發(fā)布信道有寫權(quán)限的進程可以向發(fā)布信道中按照一定的規(guī)則添加新消息；對發(fā)布信道有讀權(quán)限的進程則可以從發(fā)布信道中讀走消息。發(fā)布信道是隨內(nèi)核持續(xù)的。

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

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

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

實際上，發(fā)布服務器通過redis內(nèi)存數(shù)據(jù)庫發(fā)布系統(tǒng)進行發(fā)布。

步驟12，用戶服務器監(jiān)聽所述發(fā)布信道。

用戶服務器是與用戶終端建立直接連接的服務器，其不僅要直接連接用戶終端，處理用戶終端的消息，同時，為了及時發(fā)布頁面數(shù)據(jù)，還需要監(jiān)聽發(fā)布信道。

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

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

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

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

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

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

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

步驟13，用戶服務器根據(jù)監(jiān)聽到的發(fā)布消息將對應的發(fā)布內(nèi)容同步到本地。

用戶服務器監(jiān)聽到發(fā)布服務器發(fā)布到發(fā)布信道中的發(fā)布消息后，獲取該消息對應的發(fā)布內(nèi)容，也就是相應的頁面數(shù)據(jù)，可以保存到本地，或者不作保存。用戶服務器監(jiān)聽所述發(fā)布信道，若監(jiān)聽到發(fā)送給自身的發(fā)布消息，則將所述發(fā)布消息發(fā)送對應用戶；否則，不作處理。

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

進一步的，用戶訪問頁面數(shù)據(jù)時，在對應的用戶服務器獲取相應內(nèi)容。若所述用戶不能從對應的用戶服務器獲取所述頁面數(shù)據(jù)，則由所述用戶服務器進 行回源操作，到其它用戶服務器獲取相應頁面數(shù)據(jù)，并存儲到自身用戶服務器。然后再有相應的用戶服務器將頁面數(shù)據(jù)發(fā)送給相應用戶。

本發(fā)明實施例中，通過發(fā)布服務器將發(fā)布消息發(fā)布到發(fā)布信道；用戶服務器監(jiān)聽所述發(fā)布信道；用戶服務器根據(jù)監(jiān)聽到的發(fā)布消息將對應的發(fā)布內(nèi)容同步到本地。本發(fā)明實施例的方案，能夠在頁面數(shù)據(jù)發(fā)布時候，發(fā)布服務器進行發(fā)布信道的發(fā)布，各用戶服務器通過監(jiān)聽發(fā)布信道獲取對應的頁面數(shù)據(jù)，提高了頁面數(shù)據(jù)發(fā)布的效率，同時，在各個用戶服務器之間實現(xiàn)了負載均衡配置，不會造成網(wǎng)絡擁堵，降低了系統(tǒng)負擔，極大的提高了用戶體驗度。

如圖2所示，為本發(fā)明實施例2提供的一種頁面數(shù)據(jù)發(fā)布系統(tǒng)結(jié)構(gòu)示意圖，其中，

發(fā)布服務器21，用于將發(fā)布消息發(fā)布到發(fā)布信道；

用戶服務器22，用于監(jiān)聽所述發(fā)布信道；并根據(jù)監(jiān)聽到的發(fā)布消息將對應的發(fā)布內(nèi)容同步到本地。

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

特別的，上述用戶服務器22通過web socket協(xié)議連接到發(fā)布服務器21。發(fā)布服務器21通過redis內(nèi)存數(shù)據(jù)庫發(fā)布系統(tǒng)進行發(fā)布。

特別的，上述系統(tǒng)還包括用戶終端23，用于分別接入對應的用戶服務器22，并從所述用戶服務器22獲取所述頁面數(shù)據(jù)。若無法獲取，則由所述用戶服務器進行回源操作，到其它用戶服務器獲取相應頁面數(shù)據(jù)，并存儲到自身用戶服務器。

綜上所述，本發(fā)明實施例中，通過發(fā)布服務器將發(fā)布消息發(fā)布到發(fā)布信道；用戶服務器監(jiān)聽所述發(fā)布信道；用戶服務器根據(jù)監(jiān)聽到的發(fā)布消息將對應的發(fā)布內(nèi)容同步到本地。本發(fā)明實施例的方案，能夠在頁面數(shù)據(jù)發(fā)布時候，發(fā)布服 務器進行發(fā)布信道的發(fā)布，各用戶服務器通過監(jiān)聽發(fā)布信道獲取對應的頁面數(shù)據(jù)，提高了頁面數(shù)據(jù)發(fā)布的效率，同時，在各個用戶服務器之間實現(xiàn)了負載均衡配置，不會造成網(wǎng)絡擁堵，降低了系統(tǒng)負擔，極大的提高了用戶體驗度。

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

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

這些計算機程序指令也可存儲在能引導計算機或其他可編程數(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)。