紀(jì)培培+何頂新

摘要：該文設(shè)計(jì)與實(shí)現(xiàn)了一種符合C/S模型的WEB實(shí)時(shí)會(huì)話系統(tǒng)，使用Django框架實(shí)現(xiàn)客戶端，Erlang/OTP框架實(shí)現(xiàn)具有分布式高并發(fā)性能特性的會(huì)話服務(wù)端，應(yīng)用Comet技術(shù)在減少網(wǎng)絡(luò)消耗的同時(shí)確保會(huì)話的實(shí)時(shí)性。

關(guān)鍵詞：Django；Erlang/OTP；Comet；實(shí)時(shí)會(huì)話

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2016）08-0119-02

1 需求分析

隨著生活節(jié)奏的加快，人們對(duì)于各類WEB應(yīng)用的實(shí)時(shí)性要求也越來(lái)越高。實(shí)時(shí)通訊作為現(xiàn)代人生活中不可缺少的一部分，在各類社交系統(tǒng)中都會(huì)有所涉及，例如大型社交互動(dòng)類網(wǎng)絡(luò)游戲、大型社區(qū)服務(wù)網(wǎng)絡(luò)系統(tǒng)。筆者結(jié)合C/S結(jié)構(gòu)，設(shè)計(jì)實(shí)現(xiàn)了基于Erlang/OTP框架與django框架的實(shí)時(shí)會(huì)話系統(tǒng)，可以滿足上述大型服務(wù)系統(tǒng)中的實(shí)時(shí)通訊需求。

2 關(guān)鍵技術(shù)簡(jiǎn)介

2.1 Erlang/OTP框架

Erlang語(yǔ)言是函數(shù)式編程語(yǔ)言，也是面向并發(fā)的通用編程語(yǔ)言，引人注目的FaceBook聊天系統(tǒng)就是使用Erlang語(yǔ)言開(kāi)發(fā)，驗(yàn)證了Erlang語(yǔ)言在大規(guī)模并發(fā)活動(dòng)中的優(yōu)勢(shì)。Erlang/OTP框架可以簡(jiǎn)化Erlang應(yīng)用的開(kāi)發(fā)，使開(kāi)發(fā)者能更加專注于產(chǎn)品本身的功能實(shí)現(xiàn)，短期內(nèi)可交付產(chǎn)品級(jí)的應(yīng)用。在本次實(shí)時(shí)會(huì)話系統(tǒng)中用于實(shí)時(shí)會(huì)話系統(tǒng)的服務(wù)器端實(shí)現(xiàn)，負(fù)責(zé)并發(fā)處理大量的客戶端請(qǐng)求，以及海量用戶實(shí)時(shí)會(huì)話信息的管理。

2.2 Django框架

Django是基于Python語(yǔ)言的WEB應(yīng)用框架，采用了MVC的設(shè)計(jì)模式，即模型、視圖和控制模型，其中控制部分由框架負(fù)責(zé)，開(kāi)發(fā)者只需要關(guān)注模型、模板和視圖部分，也可以稱為MTV模型。Django的設(shè)計(jì)宗旨是能夠簡(jiǎn)便、快速的開(kāi)發(fā)數(shù)據(jù)庫(kù)驅(qū)動(dòng)的網(wǎng)站，同時(shí)注重于代碼的復(fù)用，提升開(kāi)發(fā)效率。在本次實(shí)時(shí)會(huì)話系統(tǒng)中用于實(shí)時(shí)會(huì)話系統(tǒng)的客戶端實(shí)現(xiàn)，負(fù)責(zé)與系統(tǒng)服務(wù)器交互，發(fā)送和接收用戶信息，并通過(guò)WEB頁(yè)面直觀展現(xiàn)給用戶。

2.3 Comet通訊技術(shù)

Comet是一種WEB應(yīng)用架構(gòu)，應(yīng)用該架構(gòu)可以將客戶端請(qǐng)求保存在服務(wù)器端并能保持較長(zhǎng)時(shí)間，直到預(yù)期的事件發(fā)生或者超時(shí)。一個(gè)請(qǐng)求周期結(jié)束后，又會(huì)立即發(fā)出下一個(gè)請(qǐng)求。在本次實(shí)時(shí)會(huì)話系統(tǒng)中使用Comet長(zhǎng)輪詢通訊技術(shù)來(lái)實(shí)現(xiàn)“服務(wù)器推”功能，客戶端發(fā)出請(qǐng)求后，請(qǐng)求保持在服務(wù)器端，直到有用戶實(shí)時(shí)消息到達(dá)或者等待超時(shí)事件發(fā)生時(shí)，將響應(yīng)推送給相應(yīng)客戶端。

3 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

3.1 系統(tǒng)整體設(shè)計(jì)

本次實(shí)時(shí)會(huì)話系統(tǒng)整體設(shè)計(jì)如圖1、圖2所示：

圖1所示為實(shí)時(shí)會(huì)話系統(tǒng)的功能展示，從功能上來(lái)講，整個(gè)系統(tǒng)分為兩大部分，分別為好友管理和會(huì)話信息管理，好友管理包括好友查看，增刪好友以及查找用戶功能；會(huì)話信息管理包括上線時(shí)的未讀信息反饋、給好友發(fā)送信息以及實(shí)時(shí)會(huì)話的動(dòng)態(tài)展示功能。

圖2所示為本次系統(tǒng)實(shí)現(xiàn)中較為復(fù)雜的會(huì)話信息管理部分功能，在實(shí)時(shí)會(huì)話部分，獲取當(dāng)前用戶的未讀信息，采用了Comet的長(zhǎng)輪詢通訊技術(shù)來(lái)減少通訊資源消耗，并且可以保證會(huì)話的實(shí)時(shí)性。

3.2 服務(wù)器端的設(shè)計(jì)與實(shí)現(xiàn)

實(shí)時(shí)會(huì)話系統(tǒng)服務(wù)器端應(yīng)用Erlang/OTP框架搭建，主要包括網(wǎng)關(guān)接口服、信息管理服、緩存服和數(shù)據(jù)庫(kù)服，各個(gè)子服相互獨(dú)立，可分布式部署在不同的物理機(jī)上，通過(guò)RPC遠(yuǎn)程過(guò)程調(diào)用方式實(shí)現(xiàn)相互訪問(wèn)。其中信息管理服涉及服務(wù)器端最重要的邏輯——實(shí)時(shí)獲取用戶未讀信息。

3.2.1 網(wǎng)關(guān)接口服

網(wǎng)關(guān)接口服負(fù)責(zé)請(qǐng)求的接收與響應(yīng)，當(dāng)接收到用戶請(qǐng)求時(shí)，解析相應(yīng)的數(shù)據(jù)并傳遞給信息管理服。在應(yīng)用長(zhǎng)輪詢來(lái)實(shí)現(xiàn)請(qǐng)求未讀信息功能中，設(shè)置請(qǐng)求保持為4分鐘。即若四分鐘內(nèi)，信息管理服有信息返回則返回請(qǐng)求成功的信息；若4分鐘后未收到信息管理服的信息，則視為請(qǐng)求超時(shí)，返回相應(yīng)的超時(shí)信息，結(jié)束本次請(qǐng)求。

3.2.2 信息管理服

信息管理服包括了整個(gè)系統(tǒng)的業(yè)務(wù)邏輯，首先，需要與數(shù)據(jù)庫(kù)服進(jìn)行交互，處理好友管理相關(guān)功能；其次，需要與緩存服進(jìn)行交互，處理實(shí)時(shí)信息收發(fā)相關(guān)功能。下面將復(fù)雜的實(shí)時(shí)信息處理部分進(jìn)行解析：

1） 用戶發(fā)送信息

遠(yuǎn)程同步調(diào)用緩存服，將該用戶發(fā)送的信息存儲(chǔ)在緩存中。

2） 獲取用戶未讀信息

長(zhǎng)輪詢中，設(shè)置請(qǐng)求保持時(shí)間為4分鐘，即在請(qǐng)求獲取用戶未讀信息時(shí)最多可以等待4分鐘。每一次有一個(gè)用戶請(qǐng)求到來(lái)時(shí)，開(kāi)辟兩個(gè)進(jìn)程P1和P2。P1一方面用于間隔3秒輪詢?cè)L問(wèn)緩存服，如果有信息則通過(guò)消息將信息傳遞給P2，同時(shí)結(jié)束輪詢；另一方面用于接收P2傳送過(guò)來(lái)的終止輪詢或超時(shí)信息，同時(shí)結(jié)束輪詢。P2用于控制4分鐘的請(qǐng)求時(shí)間，若4分鐘之內(nèi)接收到P1傳來(lái)的數(shù)據(jù)，則將信息返回給網(wǎng)關(guān)服；若4分鐘之內(nèi)沒(méi)有收到P1傳來(lái)的數(shù)據(jù)，則表示超時(shí)，在給P1發(fā)送終止輪詢的消息的同時(shí)將超時(shí)信息反饋給網(wǎng)關(guān)服。

3.2.3 緩存服

緩存服的設(shè)計(jì)主要是為了減少獲取數(shù)據(jù)的響應(yīng)時(shí)間，提升用戶體驗(yàn)。本次實(shí)時(shí)會(huì)話系統(tǒng)的緩存服主要實(shí)現(xiàn)如下幾個(gè)功能：

1） 緩存當(dāng)日所有用戶已讀信息

2） 緩存當(dāng)日所有用戶未讀信息并提供獲取未讀信息的接口

3） 每日凌晨系統(tǒng)維護(hù)期間，將緩存中的所有未讀和已讀信息增量補(bǔ)償?shù)綌?shù)據(jù)庫(kù)

其中功能（2）中提供獲取未讀信息的接口，用戶發(fā)送的信息會(huì)先被存儲(chǔ)到緩存服未讀信息表中，當(dāng)對(duì)應(yīng)的用戶來(lái)獲取到了該信息后，首先將該信息存入已讀信息表中，再?gòu)奈醋x信息表中刪除該信息。功能（3）中在凌晨將緩存中的昨日用戶信息增量補(bǔ)償?shù)綌?shù)據(jù)庫(kù)中，一來(lái)可以減輕緩存負(fù)擔(dān)，二來(lái)可以保證用戶信息的永久性。

3.2.4 數(shù)據(jù)庫(kù)服

數(shù)據(jù)庫(kù)服主要用于提供數(shù)據(jù)庫(kù)相關(guān)操作接口，在本次系統(tǒng)中，主要實(shí)現(xiàn)的功能有：

1） 好友信息表的維護(hù)，包括提供數(shù)據(jù)庫(kù)的好友信息的增刪查改接口和用戶查找接口。

2） 會(huì)話信息表的維護(hù)，包括提供歷史未讀信息表的管理和每日流水已讀信息表的動(dòng)態(tài)管理接口。

其中在會(huì)話信息表的維護(hù)中，由于歷史未讀信息從總量上來(lái)講比每日已讀信息要少很多，并且會(huì)動(dòng)態(tài)增加與減少，所以為了減少管理的難度和查詢所需的時(shí)間，設(shè)計(jì)了10張表，按照未讀信息用戶的id將信息映射到對(duì)應(yīng)的表中；而每日已讀信息是與日俱增的，并且總量相對(duì)大，為了便于管理和查看，采用每日動(dòng)態(tài)建表的方式將每日已讀信息存入對(duì)應(yīng)日期的表中。

3.3 客戶端的設(shè)計(jì)與實(shí)現(xiàn)

實(shí)時(shí)會(huì)話系統(tǒng)客戶端采用基于Python語(yǔ)言的Django框架設(shè)計(jì)實(shí)現(xiàn)。用戶完成登錄認(rèn)證后，首先會(huì)獲取用戶的好友列表，在會(huì)話頁(yè)面，一方面可以給好友發(fā)送信息，另一方面應(yīng)用jQuery庫(kù)Ajax技術(shù)來(lái)實(shí)現(xiàn)輪詢，查看當(dāng)前用戶是否有未讀信息。使用Ajax可以在不需要重新載入整個(gè)網(wǎng)頁(yè)的情況下，動(dòng)態(tài)更改網(wǎng)頁(yè)局部的內(nèi)容，這點(diǎn)非常適合于會(huì)話內(nèi)容的動(dòng)態(tài)更新。

其中，在請(qǐng)求當(dāng)前用戶未讀信息，客戶端對(duì)會(huì)話服務(wù)器進(jìn)行HTTP訪問(wèn)時(shí)，應(yīng)用長(zhǎng)輪詢技術(shù)，即客戶端發(fā)出請(qǐng)求后保持請(qǐng)求為4分鐘，如果4分鐘內(nèi)可以收到服務(wù)器返回的信息，則將信息交給頁(yè)面展示，如果4分鐘后服務(wù)器沒(méi)有反饋，則放棄本次請(qǐng)求，開(kāi)啟下一次長(zhǎng)輪詢請(qǐng)求。由此，可以確保用戶信息的動(dòng)態(tài)實(shí)時(shí)顯示。

4 結(jié)語(yǔ)

本文介紹的實(shí)時(shí)會(huì)話系統(tǒng)，使用Erlang/OTP框架來(lái)實(shí)現(xiàn)服務(wù)端，在實(shí)時(shí)會(huì)話功能的同時(shí)，比一般會(huì)話服務(wù)器具有更強(qiáng)的多并發(fā)能力，響應(yīng)更迅速；使用Django框架來(lái)實(shí)現(xiàn)客戶端，結(jié)合Ajax長(zhǎng)輪詢技術(shù)，可以確保當(dāng)前用戶與好友進(jìn)行實(shí)時(shí)會(huì)話。設(shè)計(jì)實(shí)現(xiàn)的系統(tǒng)用戶體驗(yàn)良好。

參考文獻(xiàn)：

[1] 張琴.基于HTTP長(zhǎng)連接的WEB實(shí)時(shí)通信技術(shù)的研究[D].電子科技大學(xué)，2014：8-10.

[2] 昊亞峰.李志昕.索依娜.用Ajax+Comet 輕松實(shí)現(xiàn)實(shí)時(shí)WEB聊天系統(tǒng)[J].電腦編程技巧與維護(hù)，2010，24（4）：