Comet技術在IM上的應用

對於數據轉發咱們通常就兩種模式，一種時推模式，一種時拉模式。下面咱們簡單介紹一下推模式和拉模式。

推模式

該模式下，通常是消息源直接推送給目標羣體或推送給Broker，由Broker推送給目標羣體。

這個模式下，每個接收者都有一份數據複製。這種狀況下，寫入壓力很是大，可是讀取的壓力很是小而且實時性很是高。是一種以空間換時間的模式。

拉模式

該模式下，通常是消息源將數據推送到存儲中，目標羣體定時或由於某些緣由觸發拉取動做。

這個模式下，全部接收者共享一份數據複製。這種狀況下，寫入壓力小，可是讀取壓力偏大，而且實時性偏弱。是一種以時間換空間的模式。

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

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

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

Comet和兩種模式的關係

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

由於有下面幾個緣由：

1. Comet請求連上服務器的瞬間，它所關注的數據已經發生了不少變化，服務器能夠馬上返回給客戶端。那麼這至關因而一個拉模式，客戶端和服務器進行了基於檢查點的同步。

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

Comet在IM上的應用

我在前面的博客中介紹了個人IM羣組設計。咱們能夠經過Comet來實現它。下面我就簡單講下如何實現該功能。

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

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

3. 若是服務器上任何channel都沒有變化，就將本身加入全部channel的訂閱中。當接收到任何變化的時候，咱們就再次遍歷全部channel，並按照前面的數據返回數據。

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