Redis在即時通訊系統中的應用

李鵬鵬，鄭揚飛，劉玉龍

（華北計算技術研究所，北京 100083）

Redis在即時通訊系統中的應用

李鵬鵬，鄭揚飛，劉玉龍

（華北計算技術研究所，北京 100083）

傳統的即時通訊系統的弊端之一是數據庫I/O次數頻繁，因為在IM中大量短而多的消息持續在磁盤的數據庫上進行讀寫。為了解決數據庫造成的系統瓶頸，選取Mysql和內存Key-Value引擎的NoSQL數據庫Redis兩級存儲，從而給出基于XMPP的即時通訊系統高可用的優化方案。

Redis；XMPP；即時通訊系統；數據分片

0 引言

即時通信[1]是以Internet網絡及有線、無線網絡為基礎物理設施，在交互雙方之間實時地傳送文本、語音和圖像等信息的通信方式。新時代的即時通訊系統，用戶需要其提供更快、更穩定、更可靠的即時通信服務。伴隨著Internet技術的不斷發展，影響網絡速度的瓶頸主要集中在訪問距離和服務器承載負荷能力方面[2]。內存數據庫以其明顯的優勢補足了傳統通信技術架構[3]的不足。本文主要介紹NoSQL在即時通訊系統中的設計與實踐。

1 Redis技術研究

1.1 Redis技術簡介

Redis[4]是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。

Redis是一個Key-Value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string（字符串）、list（鏈表）、set（集合）和zset（有序集合）。這些數據類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，Redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是Redis會周期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎上實現了master-slave（主從）同步。

Redis是一個遠程內存數據庫[5]，它不僅性能強勁，而且還具有復制特性以及為解決問題而生的獨一無二的數據模型。Redis提供了5種不同類型的數據結構，各式各樣的問題都可以很自然地映射到這些數據結構上：Redis的數據結構致力于幫助用戶解決問題，而不會像其他數據庫那樣，要求用戶扭曲問題來適應數據庫。除此之外，通過復制、持久化（persistence）和客戶端分片（client-side sharding）等特性，用戶可以很方便地將Redis擴展成一個能夠包含數百GB數據、每秒處理上百萬次請求的系統。

1.2 Redis特性

NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個輕量級的關系數據庫的名字。）

傳統的關系數據庫具有不錯的性能，高穩定型，久經歷史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯網領域，MySQL成為了絕對靠前的王者，毫不夸張的說，MySQL為互聯網的發展做出了卓越的貢獻。隨著時間的推移，線上數據越來越多，悄然進入大數據時代。網站開始快速發展，火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。巨大的流量給公司帶來了可觀的收入，也帶來了數據庫存儲與查詢并優的瓶頸。

Redis是基于C/C++開發的一款K-V數據庫，特點是運行異常快，使用協議是類Telnet。除此之外還有以下幾個特性：

● Redis持久化

通常，Redis將數據存儲于內存中，或被配置為使用虛擬內存。通過兩種方式可以實現數據持久化：使用截圖的方式，將內存中的數據不斷寫入磁盤；或使用類似MySQL的日志方式，記錄每次更新的日志。前者性能較高，但是可能會引起一定程度的數據丟失；后者相反。

● Redis主從同步

Redis支持將數據同步到多臺從庫，這種特性對提高讀取性能非常有益。

● Redis數據類型

作為Key-value型數據庫，Redis也提供了鍵（Key）和鍵值（Value）的映射關系。但是，除了常規的數值或字符串，Redis的鍵值還可以是以下形式之一：

? Lists（列表）

? Sets（集合）

? Sorted sets（有序集合）

? Hashes（哈希表）

鍵值的數據類型決定了該鍵值支持的操作。Redis支持諸如列表、集合或有序集合的交集、并集、查集等高級原子操作；同時，如果鍵值的類型是普通數字，Redis則提供自增等原子操作。

● 支持事務

Redis事務可以一次執行多個命令，并且帶有以下兩個重要的保證。第一，事務是一個單獨的隔離操作，事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷；第二，事務是一個原子操作，事務中的命令要么全部被執行，要么全部都不執行。

一個事務從開始到執行會經歷以下三個階段：開始事務，命令入隊，執行事務。

● Redis管道技術

Redis是一種基于客戶端-服務端模型以及請求/響應協議的TCP服務。這意味著通常情況下一個請求會遵循以下步驟：首先，客戶端向服務端發送一個查詢請求，并監聽Socket返回，通常是以阻塞模式，等待服務端響應；然后，服務端處理命令；最后，將結果返回給客戶端。Redis管道技術可以在服務端未響應時，客戶端可以繼續向服務端發送請求，并最終一次性讀取所有服務端的響應。

Redis其實開創了一種新的數據存儲思路，使用Redis，我們不用再面對功能單調的數據庫時，把精力放在如何把大象放進冰箱的問題，而是利用Redis提供的靈活多變的數據結構和數據操作，為不同的大象構建不同的冰箱。根據Redis的特性，總結出其最佳應用場景有：適用于數據變化快且數據庫大小可遇見（適合內存容量）的應用程序，例如：股票價格、數據分析、實時數據搜集、實時通訊。

1.3 Redis優勢分析

Redis有著更為復雜的數據結構并且提供對他們的原子性操作，這是一個不同于其他數據庫的進化路徑。Redis的數據類型都是基于基本數據結構的同時對程序員透明，無需進行額外的抽象。Redis運行在內存中但是可以持久化到磁盤，所以在對不同數據集進行高速讀寫時需要權衡內存，因為數據量不能大于硬件內存。在內存數據庫方面的另一個優點是，相比在磁盤上相同的復雜的數據結構，在內存中操作起來非常簡單，這樣Redis可以做很多內部復雜性很強的事情。同時，在磁盤格式方面他們是緊湊的以追加的方式產生的，因為他們并不需要進行隨機訪問。

Redis特點突出，正是因為這些特點所以才凸顯其以下幾個優點：

? 性能極高-Redis能讀的速度是110000次/s，寫的速度是81000次/s。

? 豐富的數據類型-Redis支持二進制案例的Strings，Lists，Hashes，Sets及Ordered Sets數據類型操作。

? 原子-Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全并后的原子性執行。

? 豐富的特性-Redis還支持publish/subscribe，通知，key過期等等特性。

2 Redis存儲設計

即時通訊系統一般分為客戶端與服務端，客戶端較輕，關鍵邏輯在服務端，一般分為三到四層，采用B/S和C/S混合架構。即時通訊系統，主要包含的業務場景有，注冊登錄、即時會話[6]、組織機構、文件傳輸。對于所有的用戶，有在線和離線的狀態。并且，對于在線狀態用戶的長連接需要有專用服務器來維護，表現在架構中的連接服務。系統邏輯架構示意圖如圖1。

2.1 數據庫詳細設計

數據庫設計圖，見圖2：

如圖2所示，根據業務邏輯層，將數據庫進行分庫設計[7]，并且每一個分片是主從設計。

初始設計使用4臺MySQL分庫。分庫的策略是：

圖1 系統邏輯架構示意圖

圖2 數據庫設計圖

如公式（1），proxyNo代表選擇Redis數據庫編號0-3。具體計算公式解釋為，使用SID（發送方用戶ID）+RID（接收方用戶ID） mod 64，0-15落在第0個庫rdb0上，16-31落在第1個庫rdb1上，32-47落在第2個庫rdb2上，48-63落在第3個庫rdb3上。這樣的優勢在于，A用戶發送B用戶和B用戶發送A用戶的消息，都會落在同一個底層數據庫。基于此設計，對于查詢用戶A和B的聊天記錄，只需要使用一個SQL查詢即可，而不需要寫腳本跨庫查詢，減少IO的開銷，以達到性能提升的效果。

分庫設計和主從備份實現了高并發和高可用的設計。但是，當Mysql單表的數據量達到1000W的時候，使用索引等對表進行優化已經到達瓶頸，所以需要從DDL、DML、DQL對數據庫進行設計。根據業務需求，在Redis上設計了消息表、用戶狀態表及其索引，并且實現兩個用戶之間消息記錄的查詢。

（a）針對聊天消息表

按照時間進行分區。基于此設計的原因在于：用戶使用場景一般為按照時間逆序查詢聊天記錄，越新的數據越熱。創建聊天表的SQL如圖3。

圖3 消息表創建sql

（b）用戶狀態表

該表主要用于維護用戶連接信息，當長鏈接被意外打斷，用此表信息恢復用戶之前狀態，起到“保留現場”的作用。創建表sql如圖4。

圖4 用戶狀態表創建sql

其中，sessionId是聊天雙方，（較小的ID在前，較大的ID在后）的會話狀態信息，pcMid是用戶pc端已讀的最大消息ID；mobileMid是用戶手機端已讀的最大消息ID；hashvalue是（發送方用戶ID+接收方用戶ID）mod 64計算后的值，為了記錄該條數據在具體的某一個數據庫中。

（c）未讀消息索引

對于未讀消息的查詢，為了實現大數據量更加高效的查詢，在數據庫中為消息表和用戶狀態表添加索引。創建索引SQL如圖5。

圖5 獲取未讀消息索引

（d）DQL未讀消息查詢

根據以上設計，查詢用戶id為1，2之間的聊天內容，優化[8]后的SQL語句如圖6。

2.2 業務場景應用

在3.1章節中介紹了數據庫的設計，并且給出了優化設計方案。針對設計的方案，我們利用具體的業務場景來完成對設計方案的試驗。首先，圖7給出的是id為1的用戶與id為2的用戶之間的文本通訊過程以及步驟。

圖6 未讀消息SQL

圖7 業務結構圖

如圖7所示，首先，定義：發送方用戶ID為srcid，接收方用戶ID為destid，每個會話的當前消息ID為msgid（針對每個發送方和接收方，自增）。

針對離線消息的場景流程如下：

1. 發送方用戶通過電腦將消息發送至Web服務器.消息主要內容（srcid，destid，msgid）

2. Web服務器根據srcid，destid獲取會話的mid（會話狀態的自增ID）

每個會話都按照較小ID在前，較大ID在后作為Redis的key，并且，每個會話的狀態信息都設置過期時間。如果Redis里沒有會話的狀態，則用時間戳填充。數據格式如表1。

3. 將消息放入持久化隊列，并且更新Redis未讀消息列表

首先將（srcid,destid,mid,msg）放入持久化隊列，然后更新Redis的用戶未讀消息列表，未讀消息列表在Redis的存儲結構如表2。

表1 公共數據區數據結構

表2 PC端未讀消息存儲結構

如表2所示，Mobile端未讀消息存儲結構和PC端設計原理一致。其中，在接收方ID的前面增加一個前綴，表明是手機未讀消息還是PC未讀消息。這個作為表結構的key。而value是一個HashMap，這個HashMap的key是發送方ID，value是未讀消息數量。

一旦用戶登錄，直接拉取該用戶的HashMap內容展示，這部分內容是有過期時間的，假如用戶長時間未使用，這個PC-destid和Mobile-destid的條目將被刪除。如果程序發現這個條目不存在.則去數據庫中查詢未讀消息列表。

假如A的ID是1000，B的ID是1001，B給A發送了三條消息，但是A一直沒有在線。程序將做如下操作：

如果此時A登錄手機客戶端，點擊未讀消息.則對Redis操作如下，刪除對應條目。

在此情況下，并且回寫數據庫一個狀態標識（已讀的最大mid）。這個回寫數據庫的過程，也是異步的，每隔30 s回寫一次數據庫狀態。這樣的設計，雖然在數據庫上對不同類型設備進行了狀態冗余，但是保證了未讀消息在不同端多次提醒。

4. 如果發送方的其他設備在線，或者接收方的設備在線，則轉發消息。

5. JAVA從隊列中異步獲取消息，然后批量Insert到數據庫。

2.3 實驗驗證

對于系統設計的方案，編寫腳本進行性能測試[9]。測試結果，如。

圖8 測試結果圖

Redis插入效率，在不使用持久化的情況下，可以達到7.3 W；在持久化情況下，保證數據最終一致性的前提下，也可以達到2.3 W。針對本文的設計，此套系統可以勝任日均超1 KW量的即時通訊任務。

3 結論

在即時通訊系統中使用Redis進行優化，為傳統IM的升級革新提供了新的思路。由于使用了無事務的NoSQL數據庫Redis，所以在本文中對所有消息有編號進行確認，類似于網絡中的ACK，解決了在故障情況下批量消息未成功發送到指定用戶端所帶來的數據丟失的問題。最后，基于Redis的即時通訊系統，相比于傳統的即時通訊系統無論在性能還是用戶體驗度都有很大的提升，達到了預期的效果。

[1] 郭鑫杰. 即時通訊系統的設計與實現[D]. 南京大學2012.

[2] 林源晟. 基于XMPP協議的即時通信服務器的設計與實現[D]. 電子科技大學 2013.

[3] 董恒競. 一種企業移動應用平臺架構設計[J]. 軟件, 2016, 37(01)∶ 136-138.

[4] 馬豫星. Redis數據庫特性分析[J]. 物聯網技術. 2015(03).

[5] 邱祝文. 基于redis的分布式緩存系統架構研究[J]. 網絡安全技術與應用. 2014(10).

[6] 張勇, 裴東良, 張會兵. 消息傳輸系統研究[J]. 軟件, 2016, 37(3)∶ 51-54.

[7] 朱思征, 王山山, 敖麗娜, 等. 大數據環境下刀具倉儲與采購智能協同研究[J]. 軟件, 2016, 37(02)∶ 29-32.

[8] 楊淙鈞, 艾中良, 劉忠麟, 等. 基于多級列式索引的海量數據高效查詢設計[J]. 軟件, 2016, 37(3)∶ 79-83.

[9] 凌高源, 朱琳. 上網流量監測管理軟件設計與實現[J]. 軟件, 2016, 37(01)∶ 48-52文獻內容.

[10] Wang S, Liu Z, Sun Q, Zou H, Yang F. Towards an accurate evaluation of quality of cloud service in service-oriented cloud computing. Journal of Intelligent Manufacturing, 2014, 25(2)∶ 283-291.

The Application of Instant Messaging System Based on Redis

LI Peng-peng, ZHENG Yang-fei, LIU Yu-long
(North China Institute of Computing Technology, Beijing 100083)

One of the drawbacks of the traditional instant messaging system is the frequent number of database I / O, because a large number of short messages in IM continue to read and write on the disk database. In order to solve the system bottleneck caused by the database, the NoSQL database Redis two-level storage of Mysql and Key-Value engine of memory is selected, and the optimization scheme of XMPP-based instant communication system is presented.

Redis; XMPP protocol; Instant Messaging system; Database sharding

TP311

A

10.3969/j.issn.1003-6970.2017.01.024

李鵬鵬(1991-），男，研究生，計算機應用技術；鄭揚飛(1976-)，男，高級工程師，主要研究方向為企業信息化，分布式系統；劉玉龍，男，高級工程師，信息系統頂層設計，信息集成

本文著錄格式：李鵬鵬，鄭揚飛，劉玉龍. Redis在即時通訊系統中的應用[J]. 軟件，2017，38（1）：115-119