Comet技術在IM上的應用

對于數據轉發我們一般就兩種模式，一種時推模式，一種時拉模式。下面我們簡單介紹一下推模式和拉模式。

推模式

該模式下，一般是消息源直接推送給目標群體或推送給Broker，由Broker推送給目標群體。

這個模式下，每一個接收者都有一份數據復制。這種情況下，寫入壓力非常大，但是讀取的壓力非常小并且實時性非常高。是一種以空間換時間的模式。

拉模式

該模式下，一般是消息源將數據推送到存儲中，目標群體定時或因為某些原因出發拉取動作。

這個模式下，所有接收者共享一份數據復制。這種情況下，寫入壓力小，但是讀取壓力偏大，并且實時性偏弱。是一種以時間換空間的模式。

兩種模式在系統設計上的影響

推模式，實現上看起來比較簡單，但考慮到訂閱群體的變化等情況，其實并不是很簡答的，并且在存儲的消耗上也是很巨大的。

拉模式，實現上觸發的隨機性很大，并且需要考慮到同步的數據的數量是否會給網絡和存儲帶來巨大的壓力。

Comet和兩種模式的關系

Comet本質上，是一個http請求服務器而服務器當前沒數據，等服務器有數據或超過一定時間才返回給客戶端。從這個層面上Comet是一個拉模式和推模式的混合體，為什么這么說？

因為有下面幾個原因：

1. Comet請求連上服務器的瞬間，它所關注的數據已經發生了很多變化，服務器可以立刻返回給客戶端。那么這相當于是一個拉模式，客戶端和服務器進行了基于檢查點的同步。

   </li>

2. Comet請求連上服務器時，它所關注的數據還沒有發生變化，在該鏈接沒有超時的階段內，數據發生了變化，服務器將數據返回給客戶端。這樣就相當等于通過拉取動作去完成了一個推模式。

   </li> </ol>

   Comet在IM上的應用
   

   我在前面的博客中介紹了我的IM群組設計。我們可以通過Comet來實現它。下面我就簡單講下如何實現該功能。

   1. 客戶端使用POST方法發起一個http請求，其中請求的形式{channel1:sync_key1},{channel2:sync_key2}。

      </li>

   2. 當服務器接收到這個請求的時候，按要求遍歷所有的channel，如果存在數據變化就以{channel1: {sync_key:sync_key1,data:[.....]},{channel2:{sync_key:sync_key2,data: [....]}}這種數據形式返回。

      </li>

   3. 如果服務器上任何channel都沒有變化，就將自己加入所有channel的訂閱中。當接收到任何變化的時候，我們就再次遍歷所有channel，并按照前面的數據返回數據。

      </li>

   4. 當客戶端收到數據返回的時候，將數據展示，同時用新的sync_key發起http請求，關注數據變化。

      </li> </ol> 來自：http://my.oschina.net/u/236698/blog/479654