楊君，徐迪

分布式即時(shí)通信系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

楊君，徐迪

（三江學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院，南京 210000）

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，即時(shí)通信軟件的出現(xiàn)大大影響人們之間的交流方式，隨著即時(shí)通信功能的越來(lái)越強(qiáng)大，人們也越來(lái)越依賴于即時(shí)通信軟軟件。但是隨著用戶量的增大，單機(jī)系統(tǒng)已經(jīng)較難支持龐大的用戶群，因此將系統(tǒng)進(jìn)行橫向的擴(kuò)展，即從單機(jī)模式轉(zhuǎn)換成分布式模式已經(jīng)成為即時(shí)通信系統(tǒng)的主流趨勢(shì)。對(duì)分布式即時(shí)通信系統(tǒng)的研究背景和意義進(jìn)行闡述，重點(diǎn)闡述系統(tǒng)的詳細(xì)設(shè)計(jì)，以及各個(gè)模塊的功能，并展示已實(shí)現(xiàn)的分布式即時(shí)通信系統(tǒng)的主要功能。

即時(shí)通信；Netty；分布式

0 引言

近年來(lái)，隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，人們衣食住行依賴于互聯(lián)網(wǎng)，人們之間的通信也開(kāi)始依賴于互聯(lián)網(wǎng)，各種即時(shí)通信軟件應(yīng)運(yùn)而生，如QQ、微信、Skype、MSN，這些即時(shí)通信軟件的出現(xiàn)使得人們可以隨時(shí)、隨地、隨身的交流。截止2016年年底，國(guó)內(nèi)即時(shí)通信用戶規(guī)模已經(jīng)達(dá)到了6.66億。QQ每日在線人數(shù)已經(jīng)達(dá)到了2.5億之多。

一個(gè)系統(tǒng)隨著用戶量的增大，一味地通過(guò)升級(jí)硬件來(lái)縱向地?cái)U(kuò)展系統(tǒng)已經(jīng)沒(méi)有了可行性，不僅因?yàn)槌杀驹絹?lái)越高，而且由于硬件瓶頸的出現(xiàn)，硬件想要快速升級(jí)已經(jīng)沒(méi)有了可能性。而且即使擁有一臺(tái)能夠支持所有用戶的機(jī)器來(lái)運(yùn)行系統(tǒng)，如果這臺(tái)機(jī)器出現(xiàn)了故障，將會(huì)導(dǎo)致所有用戶都不能夠使用，甚至導(dǎo)致數(shù)據(jù)的丟失等不可挽回的后果。所以橫向的擴(kuò)展系統(tǒng)已經(jīng)成為了不二之選，理論上可以達(dá)到無(wú)限的擴(kuò)展，但是隨著擴(kuò)展的機(jī)器增多，機(jī)器之間的管理與協(xié)作也成了隨之而來(lái)的問(wèn)題，可以想象，如果一臺(tái)機(jī)器損壞的幾率是1%，只有一臺(tái)機(jī)器的時(shí)候，感覺(jué)可以接受，但是如果是100臺(tái)機(jī)器組合起來(lái)呢，于是出現(xiàn)了許多分布式基礎(chǔ)設(shè)施來(lái)處理和解決這些需求。本課題將從眾多基礎(chǔ)設(shè)施中選出一部分來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的分布式即時(shí)通信系統(tǒng)。

1 系統(tǒng)設(shè)計(jì)

本課題實(shí)現(xiàn)的即時(shí)通信系統(tǒng)總體組成如圖2-1所示?？蛻舳死碚撋峡梢灾С秩我饪蛻舳耍菊n題客戶端僅基于網(wǎng)頁(yè)開(kāi)發(fā)，服務(wù)端可以在多臺(tái)機(jī)器上部署實(shí)現(xiàn)簡(jiǎn)單的分布式，請(qǐng)求將被轉(zhuǎn)發(fā)到不同的服務(wù)器上從而實(shí)現(xiàn)負(fù)載均衡，同時(shí)，服務(wù)端被分成多個(gè)模塊，可以在機(jī)器上任意部署。

圖1 系統(tǒng)總體設(shè)計(jì)

1.1 客戶端

客戶端功能如圖2所示，可以支持任意客戶端，只需建立socket或者websocket即可，本課題僅使用基于網(wǎng)頁(yè)開(kāi)發(fā)的客戶端驗(yàn)證功能。由于本課題重點(diǎn)在于服務(wù)端的架構(gòu)，所以所提供的業(yè)務(wù)邏輯功能只是一些基礎(chǔ)的即時(shí)通信的功能，包括注冊(cè)、登錄、初始化、好友列表、發(fā)送消息、退出、消息確認(rèn)等功能。

圖2 客戶端功能

1.2 服務(wù)端

服務(wù)端功能如圖3所示，服務(wù)端將實(shí)現(xiàn)websocket的負(fù)載均衡，socket連接的管理、消息在不同服務(wù)器之間的轉(zhuǎn)發(fā)、業(yè)務(wù)邏輯功能、日志處理等功能。其中業(yè)務(wù)邏輯功能也就是為客戶端提供的所需功能的業(yè)務(wù)邏輯，如登錄、注冊(cè)、發(fā)消息、初始化、退出、消息確認(rèn)等。

圖3 服務(wù)端功能

1.3 系統(tǒng)詳細(xì)設(shè)計(jì)

整個(gè)系統(tǒng)架構(gòu)如圖4所示，為了實(shí)現(xiàn)系統(tǒng)的解耦，整個(gè)系統(tǒng)被分為8個(gè)模塊，各個(gè)模塊各自負(fù)責(zé)相應(yīng)功能，模塊之間使用MQ實(shí)現(xiàn)通信。Nginx負(fù)責(zé)不同服務(wù)之間的負(fù)載均衡，數(shù)據(jù)庫(kù)將使用Redis作為緩存、MySQL作為持久化存儲(chǔ)。

客戶端模塊為webIM。服務(wù)端模塊為4個(gè)可運(yùn)行模塊和3個(gè)依賴模塊，可運(yùn)行模塊為webSocketServer、exchangeServer、dealUnit、imLoggerServer，分別負(fù)責(zé)連接管理、消息在服務(wù)器之間的轉(zhuǎn)發(fā)、業(yè)務(wù)邏輯處理、多機(jī)日志處理，依賴模塊將作為運(yùn)行模塊的依賴包被引入，分別為 imEntity、dealLogic、dataOperation，分別負(fù)責(zé)整個(gè)系統(tǒng)的實(shí)體類、業(yè)務(wù)邏輯處理類、數(shù)據(jù)庫(kù)操作。

下面將對(duì)各個(gè)模塊進(jìn)行消息介紹。

（1）webIM模塊

該模塊包含與用戶交互的Web頁(yè)面，在webIM中發(fā)起socket請(qǐng)求，并解析請(qǐng)求的返回值。

傳統(tǒng)的HTTP請(qǐng)求是無(wú)法實(shí)現(xiàn)被動(dòng)接受消息的，只能主動(dòng)的去請(qǐng)求從而獲得回復(fù)。最容易想到的解決方法就是輪詢，即客戶端定時(shí)向服務(wù)器發(fā)送AJAX請(qǐng)求，服務(wù)器接到請(qǐng)求后馬上返回響應(yīng)信息并關(guān)閉連接。毫無(wú)疑問(wèn)這會(huì)造成很多無(wú)用的請(qǐng)求，浪費(fèi)帶寬和服務(wù)器資源。常用的一種解決方式是長(zhǎng)輪詢，客戶端向服務(wù)器發(fā)送AJAX請(qǐng)求，服務(wù)器接到請(qǐng)求后維持住連接，直到有新消息才返回響應(yīng)信息并關(guān)閉連接，客戶端處理完響應(yīng)信息后再向服務(wù)器發(fā)送新的請(qǐng)求，但是這種方法在服務(wù)器維持連接時(shí)會(huì)消耗資源，也難于管理維護(hù)。HTML5規(guī)范的出現(xiàn)帶來(lái)了一種全新的解決方案websocket，它可以在瀏覽器和服務(wù)器之間建立TCP連接，可以做到全雙工通信，現(xiàn)在大部分瀏覽器都已經(jīng)和支持websocket。所以本課題的網(wǎng)頁(yè)端選擇websocket來(lái)實(shí)現(xiàn)。

圖4 發(fā)消息流程

由于websocket是異步處理，不是很易于開(kāi)發(fā)，所以在js中對(duì)websocket進(jìn)行了封裝。對(duì)于請(qǐng)求類消息，客戶端并不知道應(yīng)答會(huì)在什么時(shí)候返回，只需要在發(fā)起請(qǐng)求的同時(shí)注冊(cè)回調(diào)函數(shù)，在應(yīng)答返回的時(shí)候會(huì)自動(dòng)查詢到相應(yīng)的回調(diào)函數(shù)進(jìn)行執(zhí)行。返回消息和回調(diào)的對(duì)應(yīng)關(guān)系則是由請(qǐng)求包中的消息序號(hào)決定的。對(duì)于通知類消息，客戶端不知道何時(shí)會(huì)收到消息，可以在js加載的時(shí)候，把對(duì)應(yīng)消息種類的回調(diào)注冊(cè)好，之后便不需要再去關(guān)注通知類消息。

（2）webSocketServer模塊

使用Netty框架，僅僅使用少數(shù)幾個(gè)線程便可以管理所有websocket的連接和請(qǐng)求。該模塊的核心即維護(hù)了一個(gè)Map，記錄了用戶的連接和session的對(duì)應(yīng)關(guān)系，保證可以通過(guò)session找到相應(yīng)的用戶連接。

（3）exchangeServer模塊

該模塊被用于管理notice消息在不同服務(wù)器之間的轉(zhuǎn)發(fā)，在收到notice消息后，會(huì)檢查消息dataPack?ageInner包中target字段，從Redis中查詢目標(biāo)用戶的所有登錄地址，如果是在本機(jī)上登錄則直接發(fā)送給websocketServer，如果不是則根據(jù)session中的服務(wù)器地址信息找到相應(yīng)的服務(wù)器轉(zhuǎn)發(fā)。

（4）dealUnit模塊

根據(jù)不同的請(qǐng)求命令，通過(guò)工廠方法獲取dealLog?ic中相應(yīng)的類來(lái)處理業(yè)務(wù)邏輯。該模塊的存在使得業(yè)務(wù)可以任意的橫向擴(kuò)展，當(dāng)業(yè)務(wù)模塊壓力過(guò)大時(shí)，可以部署多個(gè)dealUnit模塊，只需在exchangeServer模塊做相應(yīng)的選擇，最簡(jiǎn)單的就是隨機(jī)選擇不同的dealUnit模塊。

（5）dealLogic模塊

該模塊包含了所有請(qǐng)求的業(yè)務(wù)邏輯，每一種請(qǐng)求命令都有一個(gè)對(duì)應(yīng)的處理類，在對(duì)應(yīng)的處理類中會(huì)進(jìn)行相應(yīng)的數(shù)據(jù)存取和業(yè)務(wù)邏輯處理。對(duì)于req類消息，會(huì)返回一個(gè)ack；對(duì)于notice消息，不僅會(huì)返回一個(gè)ack，還會(huì)將notice轉(zhuǎn)發(fā)給需要發(fā)送的目標(biāo)用戶。

（6）dataOperation模塊

Redis：主要存放一些緩存數(shù)據(jù)以及一些少量的id相關(guān)數(shù)據(jù)。

MySQL：主要存放一些需要同步的數(shù)據(jù)，即Redis中設(shè)置了過(guò)期時(shí)限的數(shù)據(jù)。

處理數(shù)據(jù)庫(kù)請(qǐng)求操作，包括Redis、MySQL，主要的作用在于代理Redis的請(qǐng)求，如果是讀操作，查詢Re?dis后發(fā)現(xiàn)其中沒(méi)有數(shù)據(jù)，則需要從MySQL中查詢出來(lái)存入Redis并設(shè)置有效期。如果是寫操作，并且是需要同步到MySQL中的key則Redis和MySQL中的數(shù)據(jù)都需要更新。

由于Redis是內(nèi)存數(shù)據(jù)庫(kù)，所以它的速度比關(guān)系型數(shù)據(jù)庫(kù)MySQL快得多，所以首先會(huì)去Redis中查詢數(shù)據(jù)，如果Redis中沒(méi)有才會(huì)去MySQL中查詢。但是由于Redis使用的是內(nèi)存空間，所以除了一些id關(guān)系的key，其他的存放較大數(shù)據(jù)的key都設(shè)置了有效期，并在MySQL中做了備份，在Redis中數(shù)據(jù)過(guò)期時(shí)，再?gòu)腗ySQL中查詢。雖然Redis也有VM，但是其只會(huì)在內(nèi)存不夠用的時(shí)候才會(huì)觸發(fā)。

（7）imEntity模塊

管理所有模塊公用的類，如日志發(fā)送、常量、Redis?Key、工具類等。

（8）imLoggerServer模塊

日志收集模塊，用RabbitMQ實(shí)現(xiàn)的一個(gè)簡(jiǎn)單日志收集模塊，啟動(dòng)該模塊后，會(huì)從MQ獲取所有的收集的日志數(shù)據(jù)交給log4j處理。

在單機(jī)的情況下，從imEntity獲取的日志記錄類只會(huì)調(diào)用log4j將日志輸出到本地；但是log4j并沒(méi)有提供日志的接口，所以不能實(shí)現(xiàn)不同情況使用不同的日志處理，為此slf4j提供了日志的接口使得在不同情況下使用不同的日志處理成為了可能性。在多機(jī)情況下，imEntity返回的日志類將會(huì)把日志發(fā)往MQ中。從而實(shí)現(xiàn)了簡(jiǎn)單的分布式日志的收集。

在開(kāi)啟日志的時(shí)候，各個(gè)模塊會(huì)將不同級(jí)別的日志發(fā)送到MQ的相應(yīng)級(jí)別的隊(duì)列中，在啟動(dòng)imLog?gerServer模塊時(shí)，會(huì)監(jiān)聽(tīng)相應(yīng)隊(duì)列并且做出相應(yīng)處理，本課題僅僅是將其交給log4j存于本地。

（9）流程實(shí)例

各個(gè)模塊都負(fù)責(zé)自己相應(yīng)的功能，下面以一個(gè)用戶的登錄為例，詳細(xì)說(shuō)明系統(tǒng)各個(gè)模塊的運(yùn)作流程：

①用戶打開(kāi)登錄頁(yè)面，頁(yè)面被加載，向Nginx發(fā)起創(chuàng)建socket連接的請(qǐng)求。

②Nginx接受到了websocket連接請(qǐng)求之后，根據(jù)配置，將請(qǐng)求分?jǐn)偟絯ebsocketServer上。

③websocketServer與用戶創(chuàng)建socket連接，并將該連接保存下來(lái)，之后轉(zhuǎn)發(fā)給exchangeServer模塊。

④exchangeServer接受到websocketServer發(fā)送的請(qǐng)求之后將請(qǐng)求轉(zhuǎn)給dealUnit模塊處理。

⑤dealUnit模塊接受到請(qǐng)求之后，根據(jù)請(qǐng)求的參數(shù)，發(fā)現(xiàn)是一個(gè)登錄的請(qǐng)求，調(diào)用dealLogic中相應(yīng)的業(yè)務(wù)邏輯類來(lái)處理這個(gè)請(qǐng)求。

⑥dealLogic處理登錄請(qǐng)求，從數(shù)據(jù)庫(kù)中查詢數(shù)據(jù)，看Redis中是否有用戶信息，如果沒(méi)有還需要從MySQL查詢，返回用戶的信息給dealUnit模塊，deal?Unit將返回的數(shù)據(jù)返回給exchangeServer。

⑦exchangeServer會(huì)根據(jù)信息的內(nèi)容決定是否需要轉(zhuǎn)發(fā)，由于是req類型的包，所以不需要轉(zhuǎn)發(fā)，直接轉(zhuǎn)發(fā)給websocketServer。

⑧websocketServer根據(jù)返回的內(nèi)容，從之前存儲(chǔ)的連接中找到對(duì)應(yīng)的請(qǐng)求用戶的那條連接，將數(shù)據(jù)返回給用戶。

2 系統(tǒng)實(shí)現(xiàn)

2.1 系統(tǒng)模塊功能

（1）負(fù)載均衡

負(fù)載均衡通常指將請(qǐng)求按照一定策略分?jǐn)偟蕉鄠€(gè)處理單元處理，這樣也就能夠防止單個(gè)單元的負(fù)載過(guò)高，負(fù)載均衡可以分為硬負(fù)載均衡，軟負(fù)載均衡。硬負(fù)載均衡即使用硬件來(lái)實(shí)現(xiàn)負(fù)載均衡，如F5，雖然硬件有很好的高可用性，但是成本偏高；軟負(fù)載均衡也就是通過(guò)軟件來(lái)實(shí)現(xiàn)負(fù)載均衡，常用的有Nginx的反向代理，但是如果發(fā)生了單點(diǎn)故障，整個(gè)系統(tǒng)從入口就無(wú)法進(jìn)入了，為了防止單點(diǎn)故障，最簡(jiǎn)單的方法就是配置多臺(tái)Nginx，通過(guò)DNS輪詢，將用戶的請(qǐng)求分到不同的反向代理中。當(dāng)然也可以使用LVS來(lái)代替，它使用集群技術(shù)從Linux系統(tǒng)層面實(shí)現(xiàn)了高性能、高可用、負(fù)載均衡。但是這些都存在一個(gè)問(wèn)題，它們無(wú)法保證把請(qǐng)求分給一個(gè)可用的處理單元，也就是說(shuō)如果后臺(tái)的一個(gè)處理單元發(fā)生了故障，它們并不能發(fā)現(xiàn)，仍然會(huì)將請(qǐng)求分?jǐn)傔^(guò)去，這就無(wú)法保證高可用性。為了處理這個(gè)問(wèn)題，就需要用到keepalived，它可以用來(lái)檢測(cè)服務(wù)狀態(tài)存活性。

本課題使用Nginx反向代理來(lái)實(shí)現(xiàn)websocket請(qǐng)求的負(fù)載均衡，從而將各個(gè)請(qǐng)求分發(fā)到了各個(gè)web?SockerServer模塊。

（2）模塊間通信

在本課題中，為了降低系統(tǒng)的耦合性，將整個(gè)系統(tǒng)拆分成了多個(gè)模塊，但是各個(gè)模塊之間的相互通信就成了亟待解決的問(wèn)題，如果是單機(jī)的進(jìn)程通信，Linux可以使用管道（pipe），但是多臺(tái)機(jī)器之間模塊的通信，只能通過(guò)手動(dòng)創(chuàng)建socket去進(jìn)行數(shù)據(jù)的交互了，消息隊(duì)列中間件就是對(duì)這一系列問(wèn)題的解決與完善，內(nèi)置完善的處理機(jī)制，實(shí)現(xiàn)了高性能，高可用，可伸縮和最終一致性架構(gòu)。常用的消息隊(duì)列有ActiveMQ，Rabbit?MQ，ZeroMQ，Kafka，RocketMQ等。消息隊(duì)列中間件是分布式系統(tǒng)中重要的組件，主要解決應(yīng)用耦合，異步消息，流量削鋒等問(wèn)題。

本課題使用RabbitMQ作為消息中間件來(lái)實(shí)現(xiàn)各個(gè)模塊的通信和解耦。

（3）分布式緩存

當(dāng)傳統(tǒng)數(shù)據(jù)庫(kù)面臨大規(guī)模數(shù)據(jù)訪問(wèn)時(shí),磁盤I/O往往成為性能瓶頸,從而導(dǎo)致過(guò)高的響應(yīng)延遲。分布式緩存將高速內(nèi)存作為數(shù)據(jù)對(duì)象的存儲(chǔ)介質(zhì),數(shù)據(jù)以key/value形式存儲(chǔ),理想情況下可以獲得內(nèi)存級(jí)的讀寫性能。

本課題在dataOperation模塊中使用Redis作為緩存，從而提高I/O的讀寫。

（4）分布式日志收集

單機(jī)上的日志處理，只需要把日志輸出到相應(yīng)的文件或是其他地方就可以了，有類似于log4j、slf4j等豐富的類庫(kù)可以通過(guò)簡(jiǎn)單的配置非常容易的實(shí)現(xiàn)日志的處理。而一旦轉(zhuǎn)移到多臺(tái)機(jī)器上，日志的收集就會(huì)變得復(fù)雜。

本課題在imLoggerServer中使用RabbitMQ實(shí)現(xiàn)一個(gè)非常簡(jiǎn)單了日志收集模塊。

2.2 系統(tǒng)業(yè)務(wù)邏輯

（1）注冊(cè)

在用戶填寫完注冊(cè)信息之后，會(huì)向服務(wù)端發(fā)起注冊(cè)請(qǐng)求，服務(wù)器在接受到用戶名密碼之后，會(huì)將密碼加salt后取得MD5存入到MySQL和Redis中。

（2）登錄

服務(wù)器在接受到賬號(hào)密碼，驗(yàn)證了賬號(hào)密碼的合法性之后，會(huì)將登錄者本次連接的session存入Redis，以便別人找到該用戶登錄的服務(wù)器。在socket斷開(kāi)之后，服務(wù)端會(huì)自動(dòng)調(diào)用下線指令去刪除Redis中的ses?sion等數(shù)據(jù)。

（3）初始化

在客戶端收到成功登錄的ack之后，會(huì)發(fā)起初始化請(qǐng)求，拉取好友和SYNC序號(hào)等信息。

（4）發(fā)消息

可以給好友發(fā)送消息，支持一個(gè)用戶同時(shí)在多個(gè)地方登陸。具體流程如圖5所示。

圖5 發(fā)消息流程

如果用戶C1在服務(wù)器S1上登錄，用戶C2在服務(wù)器S2上登錄，C1發(fā)送消息給C2時(shí)，服務(wù)器C1在收到notice消息之后，會(huì)返回給C1一個(gè)ack告知客戶端服務(wù)器成功收到消息，這條消息在經(jīng)過(guò)dealUnit被返回到exchangeServer的時(shí)候，exchangeServer查詢r(jià)edis后發(fā)現(xiàn)用戶C2所登錄的服務(wù)器不是當(dāng)前服務(wù)器，于是轉(zhuǎn)發(fā)給C2所在服務(wù)器S2。S2的exchangeServer收到之后轉(zhuǎn)發(fā)給了它的websocketServer，最終C2成功接受到了notice消息。

（5）消息確認(rèn)

針對(duì)于notice消息的防丟包機(jī)制，由于notice消息只是被動(dòng)的接受，如果服務(wù)器發(fā)送了這條消息，但是用戶沒(méi)有接收到，這就導(dǎo)致了消息存在丟失的風(fēng)險(xiǎn)，于是增加了同步（synchronize,sync）機(jī)制。

用戶在登錄時(shí)，會(huì)返回該用戶最新的sync序號(hào)，存入本地。服務(wù)器在轉(zhuǎn)發(fā)notice消息之前，會(huì)給這條消息增加一個(gè)序號(hào)，并將該條消息保存，在客戶端接受到消息后，將這條消息的序號(hào)與本地的sync消息序號(hào)對(duì)比，如果發(fā)現(xiàn)本地的序號(hào)等于消息的序號(hào)加一，則說(shuō)明之前沒(méi)有丟失的消息，客戶端會(huì)發(fā)送一條特定的req（FIN消息）告知服務(wù)器它成功接收到了消息，服務(wù)器在接受到該條req后，會(huì)返回一個(gè)ack，并將那條保存的notice刪除。如果客戶端發(fā)現(xiàn)本地的序號(hào)不對(duì)，則發(fā)送一條req（sync消息），告知服務(wù)器將該序號(hào)之后的數(shù)據(jù)再發(fā)一遍。

3 結(jié)語(yǔ)

本課題主要專注于服務(wù)端的架構(gòu)，結(jié)構(gòu)上實(shí)現(xiàn)了負(fù)載均衡、模塊間通信、連接管理、分布式緩存、分布式日志收集等功能，實(shí)現(xiàn)了服務(wù)端的橫向擴(kuò)展，業(yè)務(wù)邏輯上則實(shí)現(xiàn)了一些簡(jiǎn)單的即時(shí)通信系統(tǒng)功能，如注冊(cè)、登錄、初始化、好友信息、發(fā)送消息、消息確認(rèn)等功能。

[1]李代立,陳榕.WebSocket在Web實(shí)時(shí)通信領(lǐng)域的研究[J].電腦知識(shí)與技術(shù)，2010,06（28）:7923-7925

[2]李璐,張廣泉.消息中間件的體系結(jié)構(gòu)研究[J].蘇州大學(xué)學(xué)報(bào)（工科版），2007,27（3）:10-14

[3]代超,鄧中亮.基于Netty的面向移動(dòng)終端的推送服務(wù)設(shè)計(jì)[J].軟件，2015（12）:1-4

[4]曾超宇,李金香.Redis在高速緩存系統(tǒng)中的應(yīng)用[J].微型機(jī)與應(yīng)用，2013,32（12）:11-13

[5]劉影,季波.企業(yè)級(jí)即時(shí)通信系統(tǒng)的應(yīng)用研究[J].現(xiàn)代商貿(mào)工業(yè)，2009,19（20）:36-36

Design and Implementation of Distributed Instant Messaging System

YANG Jun，XU Di
（School of Computer Science and Engineering,Sanjiang University,Nanjing 210000）

With the continuous development of Internet technology,instant communication software has greatly affected the communication between the people,with the instant communication function more and more powerful,more and more people rely on instant communication soft?ware.But with the increase of the number of users,the stand-alone system has been difficult to support the huge user base,so for the hori?zontal expansion of the system,from the stand-alone mode into a distributed mode has become the mainstream trend of instant messaging system.Describes the research background and significance of the distributed instant messaging system,and then focuses on the detailed design of the system,as well as the function of each module.Finally,presents the main functions of the distributed instant messenger sys?tem.

Instant Messaging;Netty;Distributed System

1007-1423（2017）24-0071-05

10.3969/j.issn.1007-1423.2017.24.017

楊君，講師，研究方向?yàn)榉植际接?jì)算

徐迪（1995-），男，江蘇南京人，工程師，研究方向?yàn)榉植际较到y(tǒng)、軟件工程

2017-05-25

2017-08-12