我們先以聊天室為例來講， web聊天室的實(shí)現(xiàn)方法有多種，包括：基于ajax技術(shù)的實(shí)現(xiàn)，基于Comet（Pushlet）技術(shù)的實(shí)現(xiàn)，基于XMPP協(xié)議的實(shí)現(xiàn)，以及基于flash的XmlSocket和遠(yuǎn)程共享對象的實(shí)現(xiàn)。

  （1）基于ajax技術(shù)的實(shí)現(xiàn)。

  ajax（異步JavaScript和XML，Asynchronous javascript and xml），它的作用就是可以實(shí)現(xiàn)頁面與服務(wù)器端的無刷新交互。用ajax來實(shí)現(xiàn)web聊天室的基本原理是：在頁面上每隔一段時間就通過ajax從服務(wù)器中 獲取數(shù)據(jù)，然后更新頁面顯示。這種方法簡單明了，缺點(diǎn)是實(shí)時性不高。

  （2） 基于Comet技術(shù)的實(shí)現(xiàn)。

  Comet 是一種新的 Web 應(yīng)用架構(gòu)?；谶@種架構(gòu)開發(fā)的應(yīng)用中，服務(wù)器端會主動以異步的方式向客戶端程序推送數(shù)據(jù)，而不需要客戶端顯式的發(fā)出請求。Comet 架構(gòu)非常適合事件驅(qū)動的 Web 應(yīng)用，以及對交互性和實(shí)時性要求較高的應(yīng)用，如股票交易行情分析、聊天室和 Web 版在線游戲等。

  Pushlet是一種comet實(shí)現(xiàn)（Pushlet 是開源的Comet 框架）：在Servlet機(jī)制下，數(shù)據(jù)從服務(wù)器的Java對象直接推送（push）到客戶端的頁面，而無需任何Java applet或者插件的幫助。它使server端可以周期性地更新client的web頁面，這與傳統(tǒng)的request/response方式不同。

  Pushlet基于HTTP流，這種技術(shù)常常用在多媒體視頻、通訊應(yīng)用中，比如QuickTime。與裝載HTTP頁面之后馬上關(guān)閉HTTP連接的做法相 反，Pushlet采用HTTP流方式將新數(shù)據(jù)源源不斷地推送到client，再此期間HTTP連接一直保持打開。有關(guān)如何在Java中實(shí)現(xiàn)這種 Keep-alive的長連接請參看Sun提供的《HTTP Persistent Connection》和W3C的《HTTP1.1規(guī)范》。

  （3）基于XMPP協(xié)議的實(shí)現(xiàn)

  XMPP（可擴(kuò)展消息處理現(xiàn)場協(xié)議）是基于XML的協(xié)議，是專為及時通信系統(tǒng)設(shè)計(jì)的通信協(xié)議，用于即時消息以及在線現(xiàn)場探測。它在促進(jìn)服務(wù)器之間的準(zhǔn)即時 操作。這個協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何人發(fā)送即時消息，即使其操作系統(tǒng)和瀏覽器不同。XMPP的前身是Jabber，一個開源形式組 織產(chǎn)生的網(wǎng)絡(luò)即時通信協(xié)議。著名的開源聊天系統(tǒng)服務(wù)器Openfire就是基于XMPP協(xié)議的Jabber服務(wù)器。

  可以通過Flash或ajax與Jabber服務(wù)器進(jìn)行交互，實(shí)現(xiàn)webIM的功能，

  （4）基于flash的XmlSocket的實(shí)現(xiàn)

  Flash Media Server是一個很強(qiáng)大的流媒體服務(wù)器，它基于rtmp協(xié)議，提供了強(qiáng)壯的流媒體交互功能。在FMS中，提供一種遠(yuǎn)程共享對象（SharedObject） 的機(jī)制，客戶端可以創(chuàng)建并連接到服務(wù)器端的遠(yuǎn)程共享對象?？梢杂泻芏鄠€客戶端連接到同一個遠(yuǎn)程共享對象中，任何一個客戶端對共享對象進(jìn)行了修改，服務(wù)器都 會將共享對象的修改信息發(fā)送給所有其他連接到這個共享對象的客戶端。這種遠(yuǎn)程共享對象的機(jī)制可以很方面地實(shí)現(xiàn)以下功能：·    遠(yuǎn)程控制幻燈片放映  ·    文字聊天  ·    網(wǎng)絡(luò)對戰(zhàn)  ·    遠(yuǎn)程選擇和播放歌曲  ·    現(xiàn)場拍賣  ·   客戶服務(wù)應(yīng)用程序。

  遠(yuǎn)程共享對象很適合用于實(shí)現(xiàn)web聊天室中的群聊功能。為每一個群都建立一個遠(yuǎn)程共享對象，這樣的話，任何用戶在群上發(fā)信息，就可以通過服務(wù)器自動發(fā)送到所有的群成員。

  用遠(yuǎn)程共享對象來實(shí)現(xiàn)單聊是不實(shí)際的。對應(yīng)單聊的實(shí)現(xiàn)，我們需要借助socket?？蛻舳送ㄟ^socket服務(wù)器與其他客戶端進(jìn)行私聊。聊天信息通過socket服務(wù)器進(jìn)行轉(zhuǎn)發(fā)。

  這種方式是效率最高的web聊天室實(shí)現(xiàn)方式。

即時通訊系統(tǒng)架構(gòu)
簡單地介紹一下大型商業(yè)應(yīng)用的IM系統(tǒng)的架構(gòu)。設(shè)計(jì)這種架構(gòu)比較重要的一點(diǎn)是低耦合，把整個系統(tǒng)設(shè)計(jì)成多個相互分離的子系統(tǒng)。我把整個系統(tǒng)分成下面幾個部分：（1）狀態(tài)消息系統(tǒng)   （2）好友系統(tǒng)   （3）P2P系統(tǒng)    （4）其他擴(kuò)展業(yè)務(wù)系統(tǒng)

先看狀態(tài)消息系統(tǒng)

（1）connd 
client接入服務(wù)器，可以支持UDP，也可以支持TCP，一般建議優(yōu)先選擇TCP。connd可以布置多臺，client接入時，可以用簡單的DNS輪詢的方式實(shí)現(xiàn)負(fù)載均衡。connd功能是維護(hù)連接和轉(zhuǎn)發(fā)消息包。

（2）pconnd
proxy connd, 代理接入服務(wù)器，是connd的擴(kuò)展，除了有connd的功能外，支持服務(wù)器的接入，比如web server。

（3）msgd
消息處理服務(wù)器，主要功能是用戶狀態(tài)管理，消息轉(zhuǎn)發(fā)(包括合理性驗(yàn)證)以及離線消息保存。

說一個用戶登錄成功后，對所有好友的狀態(tài)通知過程。我設(shè)計(jì)的系統(tǒng)中，把用戶狀態(tài)也簡單看成類似文本聊天消息。下面用戶U的上線過程，他有好友F1, F2。
（1） connd收到U上線消息，將消息發(fā)給U所在的msgd。

（2） msgd獲取U的好友，F(xiàn)1, F2；如果F1, F2和U不在同一個msgd上，msgd將消息通過connd轉(zhuǎn)給F1, F2所在的msgd。

（3） 最終的msgd把上線通知通過connd發(fā)給F1, F2。

msgd的U是通過什么方式獲取最新的好友呢？ 這個問題我要著重描述一下。

用戶的好友數(shù)據(jù)都在另外一個子系統(tǒng)中：好友子系統(tǒng)。 msgd通過TCP的方式（為什么用TCP呢？）主動從好友系統(tǒng)獲取。同時，msgd也緩存一份好友數(shù)據(jù)。msgd獲取用戶好友時，如果cache是最新的，直接從cache取，否則要從好友子系統(tǒng)那邊取。現(xiàn)在重點(diǎn)問題出來了，如何確定用戶的好友是最新的？這類問題我們要根據(jù)不同的業(yè)務(wù)不同的特點(diǎn)靈活采用不同的方法。請看一種高效的處理方式：

（1） 好友子系統(tǒng)為每個用戶的好友算個hash值（可以用MD5）。

（2） client獲取好友時，同時也拿到這個hash值；發(fā)和好友相關(guān)的消息時，把hash值帶給msgd。

（3） msgd第一次從好友子系統(tǒng)獲取某個用戶好友時，也獲取這個hash值；像要轉(zhuǎn)發(fā)狀態(tài)消息，獲取好友時，把client帶過來的hash1和自身的hash2比較一下。。。

像IM這種業(yè)務(wù)特點(diǎn)是，對好友數(shù)據(jù)的寫很少，讀很多，相對于讀的消耗，寫基本可以忽略的。用上面的方法，基本上每次兩者的hash值是相等的，直接從cache拿好友數(shù)據(jù)。這種處理方法也可以引入到其他應(yīng)用業(yè)務(wù)中。建議不要每次都粗暴地跨進(jìn)程獲取類似好友數(shù)據(jù)。

最新評論