訊息系統該Push Pull模式分析

資訊推拉技術簡介

「智慧型資訊推拉(iipp)技術」是在網上資訊獲取技術中加入了智慧型成份，從而有助於使用者在海量資訊中高效、及時地獲取最新資訊，提高了資訊系統主動資訊服務的能力。如果引入基於iipp的主動資訊服務系統，則可根據使用者的特性提供具有針對性的、個性化的資訊服務。

以往在internet上搜尋資訊，最常用的方法就是瀏覽器發出請求後，web就將資訊傳送給使用者，此過程使用者需要「拉取」資訊而被描述為pull；而將資訊直接「推送」到使用者的計算機的方法就是資訊推送，稱之為push，使用者只需要在初次使用時自己設定所需要的資訊頻道，此後，定製資訊將通過web自動傳給使用者。

資訊推拉技術智慧型化

在傳統的client/server結構中，資訊獲取方式是按「拉」(pull)的模型進行的：伺服器根據使用者終端傳送的服務請求進行處理並返回使用者所需的結果。在push系統中，伺服器把資訊「推」給使用者終端系統。雖然兩者資料傳輸的方向都是從伺服器流向使用者，但操作的發起者是不同的。從「信源」與「使用者」的關係來看，資訊的流動可分為兩種模式，即資訊推送與資訊拉取模式。

push與pull之比較

推送(push)技術是根據使用者需要，有目的、按時將使用者感興趣的資訊主動傳送到使用者的計算機中。push技術的主要優點是對使用者要求低，普遍適用於廣大公眾，不要求有專門的技術；二是及時性好，信源及時地向使用者「推送」不斷更新的動態資訊。但是，在隨後實際應用中，因為存在以下幾方面不足，push技術並沒有取得預期的成功：

１.　不能確保傳送成功。由於push技術採用廣播方式，當網路資訊中心傳送資訊時，只有接收器開啟並正好切換到同一頻道上，傳輸才能發生作用，使用者才能獲取資訊。這對於那些要確保能收到資訊的應用領域是不太適合的。

２.　沒有資訊狀態跟蹤。push技術採用的是「開環控制」模式，乙個資訊發布以後的狀態，如使用者是否接收，或客戶端收到後是否按資訊的提示執行了任務等，這些「反饋資訊」發布者無從得知。

３.　針對性差。推送的資訊內容缺乏針對性，不能滿足使用者的個性化需求。有價值的重要資訊，通常都是要針對一些特定的群組來傳送的，即只送給相關的人士。push技術不能滿足上述需求。

４.　信源任務重。信源系統要主動地、快速地、不斷地將大量資訊推送給使用者。

拉取(pull)技術指使用者有目的地在網路上主動查詢資訊，使用者從瀏覽器給web發出請求，由web獲取所需資訊。面對擁有海量資訊的internet環境，搜尋引擎是有效的網路資訊「拉取」(查詢)的檢索工具。pull技術的主要優點是針對性強，能滿足使用者的個性化需求；資訊傳輸量小，網路上所傳輸的只是使用者的請求和伺服器針對該請求所作的響應；信源任務輕，資訊系統只是被動接受查詢，提供使用者所需的部分資訊。其主要缺點是及時性差，由於使用者只會基於自己的知識水平(或專業水平)提出請求，當信源中資訊更新變化時，使用者難以及時拉取新的動態資訊，雖然可以通過定時查詢來解決這個問題，但是會浪費大量的網路資源和人力，而且，仍不能保證最好的實時性。對使用者要求高，要求使用者對信源系統有相應的專業知識，掌握相關的檢索技術。

push和pull兩種模式結合

將資訊推送與拉取兩種模式結合能做到取長補短，使二者優勢互補。根據推、拉結合順序及結合方式的差異，又分以下四種不同推拉模式：

先推後拉——先由信源及時推送公共資訊，再由使用者有針對性地拉取個性化資訊；

先拉後推——根據使用者拉取的資訊，信源進一步主動提供(推送)與之相關的資訊；

推中有拉——在資訊推送過程中，允許使用者隨時中斷並定格在感興趣的網頁上，以拉取更有針對性的資訊；

拉中有推——根據使用者搜尋(即拉取)過程中所用的關鍵字，信源主動推送相關的最新資訊。

push和pull模型對比

無論是訊息系統，還是配置管理中心，甚至儲存系統，你都要面臨這樣乙個選擇，push模型 or pull模型?是服務端主動給客戶端推送資料，還是客戶端去伺服器拉資料，一張圖表對比如下：

在面對大量甚至海量客戶端的時候，使用push模型，儲存大量的狀態資訊是個沉重的負擔，加上覆制n份資料分發的壓力，也會使得實時性這唯一的優點也被放小。使用pull模型，通過將客戶端狀態儲存在客戶端，大大減輕了伺服器端壓力，通過客戶端自身做流量控制也更容易，更能發揮客戶端的處理能力，但是需要面對如何在這些客戶端之間做協調的難題。

實現乙個簡單的服務端推方案

客戶端和服務端的互動有推和拉兩種方式：如果是客戶端拉的話，通常就是polling；如果是服務端推的話，一般就是comet，目前比較流行的comet實現方式是long polling。

先來看看polling，它其實就是我們平常所說的輪詢，大致如下所示：

因為服務端不會主動告訴客戶端它是否有新資料，所以polling的實時性較差。雖然可以通過加快輪詢頻率的方式來緩解這個問題，但相應付出的代價也不小：一來會使負載居高不下，二來也會讓頻寬捉襟見肘。

再來說說long polling，如果使用傳統的lamp技術去實現的話，大致如下所示：

客戶端不會頻繁的輪詢服務端，而是對服務端發起乙個長連線，服務端通過輪詢資料庫來確定是否有新資料，一旦發現新資料便給客戶端發出響應，這次互動便結束了。客戶端處理好新資料後再重新發起乙個長連線，如此周而復始。

在上面這個long polling方案裡，我們解決了polling中客戶端輪詢造成的負載和頻寬的問題，但是依然存在服務端輪詢，資料庫的壓力可想而知，此時我們雖然可以通過針對資料庫使用主從複製，分片等技術來緩解問題，但那畢竟只是治標不治本。

我們的目標是實現乙個簡單的服務端推方案，但簡單絕對不意味著簡陋，輪詢資料庫是不可以接受的，下面我們來看看如何解決這個問題。在這裡我們放棄了傳統的lamp技術，轉而使用nginx與lua來實現。

此方案的主要思路是這樣的：使用nginx作為服務端，通過lua協程來建立長連線，一旦資料庫裡有新資料，它便主動通知nginx，並把相應的標識(比如乙個自增的整數id)儲存在nginx共享記憶體中，接下來，nginx不會再去輪詢資料庫，而是改為輪詢本地的共享記憶體，通過比對標識來判斷是否有新訊息，如果有便給客戶端發出響應。

注：服務端維持大量長連線時核心引數的調整請參考：http長連線200萬嘗試及調優。

首先，我們簡單寫一點**實現輪詢(篇幅所限省略了查詢資料庫的操作)：

server

...}

注：為了解決服務端不知道客戶端何時斷開連線的情況，**中引入超時機制。

其次，我們需要做一些基礎工作，以便操作nginx的共享記憶體：

server

...}

如果要寫nginx共享記憶體的話，可以這樣操作：

如果要讀nginx共享記憶體的話，可以這樣操作：

當資料庫有新資料的時候，可以通過觸發器來寫nginx共享記憶體，當然，在應用層通過觀察者模式來寫nginx共享記憶體通常會是乙個更優雅的選擇。

如此一來，資料庫就徹底翻身做主人了，雖然系統仍然存在輪詢，但已經從輪詢別人變成了輪詢自己，效率不可相提並論，相應的，我們可以加快輪詢的頻率而不會造成太大的壓力，從而在根本上提公升使用者體驗。

突然想起另乙個有趣的服務端推的做法，不妨在一起嘮嘮：如果db使用redis的話，那麼可以利用其提供的blpop方法來實現服務端推，這樣的話，連sleep都不用了，不過有一點需要注意的是，一旦使用了blpop方法，那麼nginx和redis之間的連線便會一直保持下去，從redis的角度看，nginx是客戶端，而客戶端的可用埠數量是有限的，這就意味著一台nginx至多只能建立五六萬個連線(net.ipv4.ip_local_port_range)，有點兒少。

當然，本文的描述只是滄海一粟，還有很多技術可供選擇，比如pub/sub，websocket等等，篇幅所限，這裡就不多說了，有興趣的讀者請自己查閱。

訊息系統該Push Pull模式分析

訊息系統該Push Pull模式分析

訊息系統該Push Pull模式分析

Push Pull模式分析

相關推薦