基于Epoll模型的消息推送研究與實現

2016-06-17 09:32:40朱曉姝孫小雁

合肥工業大學學報(自然科學版) 2016年4期

邱　杰,朱曉姝,孫小雁

(玉林師范學院計算機科學與工程學院，廣西玉林　537000)

基于Epoll模型的消息推送研究與實現

邱杰,朱曉姝,孫小雁

(玉林師范學院計算機科學與工程學院，廣西玉林537000)

摘要:當前消息推送已成為網絡消息傳遞的一種主流方式,特別在移動平臺上得到廣泛應用，淘寶、QQ及微信等大型交流平臺都使用消息推送方式。在Linux系統下的Epoll模型是一種優秀的通信模型,它優于Select模型和Poll模型,在連接數量上限制很小,并且對CPU的負擔比較小。文章基于Epoll模型和長連接方法設計一種新的消息推送方法,并與國際流行的消息推送方法進行對比仿真實驗,實驗結果表明,基于Epoll模型的消息推送方法在及時性與連接數量耗時上均優于傳統的方法。

關鍵詞:消息推送;Epoll模型;Linux系統;長連接;數據包

0引言

隨著互聯網與移動平臺的快速發展,淘寶、QQ、微信及Facebook等都已經把重點方向轉移到移動端方面[1],它們對在移動平臺上的消息發送與獲取都有很高的需求和期待,特別是在及時性方面,要求發送與接收的信息必須在規定的時間內送達與收到。消息推送方式則應運而生,消息推送的服務器會不斷地更新信息,通過建立一條手機與服務器的連接鏈路,當有更新好的消息需要發送到手機時,通過此鏈路發送即可。與傳統的發送方式相比,消息推送減少了服務器與客戶端的交互次數和通信時間,提高了通信效率,而且是由服務器直接將更新好的消息推送過去,并不需要客戶端主動參與,客戶端可以第一時間獲取更新的消息[2]。

基于消息推送的上述優點,近年來消息推送方式將會是主流的消息發送方式。本文提出一種基于Epoll模型的消息推送方式,這種方式可以提高消息推送的效率。

1消息推送的原理

消息推送的流程[3-4]如下:

(1)啟動服務器與客戶端。

(2)客戶端請求連接服務器,并建立基于TCP協議的長連接。

(3)服務器端獲取或者更新消息,可以由其他網絡系統或者自行循環掃描獲得。

(4)服務器把消息放入一個由內存制造出來的隊列中。

(5)服務器把消息發送給客戶端。

(6)客戶端接收到消息并做異步處理。

在上述推送過程中,要注意以下4點[5-6]:

(1)要保證服務器正常運行,則需要在服務端開一個監控服務,用來監控這個服務端正常運行。如果服務端異常,強制重啟,并返回一個通知。

(2)為了保證服務器與客戶端不中斷連接,服務端每25 s給客戶端發送一個特定消息包或者稱之為心跳包。如果客戶端收到這個心跳包,說明連接是正常的,如果未收到則說明這個包連接已經中斷,此時客戶端的監控程序監控到中斷,就會強制重啟客戶端,并再次與服務端進行連接。

(3)為確保服務端與客戶端之間通信所傳送數據的完整性,兩端之間用json格式進行傳輸,然后在對方得到數據后進行反序列化解析,如果格式不正確則丟棄。

(4)數據傳輸過程中為了防止數據丟失,服務端會每15 min檢查1次,如果用戶沒有獲取信息,則說明客戶端掉線,在下次連接后,再把斷線這個時間段積累的消息發給客戶端。

當前使用比較多的消息推送機制有輪詢與長連接2種:① 輪詢(polling),客戶端階段性地與服務器進行連接并查詢服務器是否有新的消息送達,必須保持兩者之間時刻處于通信狀態,要考慮輪詢的頻率,若太慢可能導致某些消息的延遲,若太快則會消耗大量網絡帶寬;② 長連接,這個方案可以解決由輪詢帶來的性能問題。

2Epoll模型

2.1Epoll模型的特點

Epoll模型是Linux環境下的通信模型,Linux環境中的并行通信方式有很多種類型,主要支持的I/O模型有Select、Poll和Epoll 3種模型[7]。

Select模型的最大并發數是受限制的，掃描頻繁導致效率比較低，提取信息的方式是內存拷貝,從而導致提取速度非常慢。

Poll模型和Select模型具有相近的效率,性能測試發現,Select模型與Poll模型有相似的時間調用與CPU資源占用率,在活動連接數量不變的情況下,隨著數據量的增加或連接數的增加，系統資源的消耗也相應增加。Poll模型也存在著Select模型的2個缺點。Poll模型被用于Polling消息推送上,它是一個被動推送的過程,客戶端對服務器做輪詢,服務器方監聽到輪詢后就會給客戶端發送更新的消息,輪詢頻率過密會使服務器負擔加重,輪詢間隔太久,獲取消息的及時性又不好[8-9]。

Epoll模型與上述2種模型相比,沒有最大并發連接的限制,連接上限與系統內存有關,即內存越大能并發的連接就越多。Epoll另一個優點在于它只管“活躍”地并發連接數量,而不用去管連接總數的多少,因此在實際的網絡環境中,Epoll模型的效率會遠遠高于Select模型和Poll模型。Epoll模型對信息的提取使用了“共享內存”,省略了內存拷貝,從而避免了巨大的資源消耗。

由此可見,Epoll模型是一種高并發和高承載I/O方式,可以用在大型的服務器線程處理上。在Linux系統下,每訪問1個連接就要創建1個socket句柄,當需要訪問很多時就會創建很多的句柄,從而使服務器消耗大量的資源,服務器也會進入監聽新句柄的狀態,而使用Epoll模型就可以解決這個問題,服務器不會在監聽新句柄上浪費資源,Epoll模型支持socket集合的return,不需要在socket上進行一次次遍歷。

2.2Epoll模型的接口

Epoll的接口主要有以下3個函數:

(1)int epoll-create(int size)。此函數可創建一個epoll的句柄。

(2)int epoll-ctl(int epfd，int op，int fd，struct epoll-event *event)。該函數是epoll的事件注冊函數,不同于Select模型中監聽事件時指示內核要監聽什么類型的事件,而是先注冊要監聽的事件類型,然后監聽相應事件類型即可。其中event有7個宏,分別是：EPOLLIN，表示可以讀出對應的文件描述符;EPOLLOUT，表示可以寫入對應的文件描述符;EPOLLPRI，表示對應的文件描述符有緊急的數據可讀;EPOLLERR，表示對應的文件描述符發生錯誤;EPOLLHUP，表示對應的文件描述符已經被掛斷;EPOLLET，將EPOLL設為Edge Triggered模式,這是相對于Level Triggered來說的；EPOLLONESHOT，只監聽一次事件,當監聽完這次事件后,如果還需要繼續監聽該socket的話,需要再次把socket加入到EPOLL隊列里。

(3)int epoll-wait(int epfd，struct epoll-event * events，int maxevents，int timeout)。該函數是等待監聽的事件發生。Epoll模型有如下2種工作方式:① 水平觸發方式,該方式在套接字下可以支持處理阻塞與非阻塞工作模式;② 邊緣觸發方式,該方式只能支持處理非阻塞工作模式,因此它是一種快速的工作方式,沒有阻塞干擾。

3Epoll-MP的設計與實現

3.1Epoll-MP服務構架與程序結構

基于Epoll模型的消息推送(epoll massege push,Epoll-MP)服務構架如圖1所示。

由圖1可看出，客戶端上線后,首先連接推送消息服務器,并發送第1條身份驗證的消息,將自己的ID組、播號等信息發送給服務器；服務器收到驗證消息后,將驗證消息及其文件描述符插入到連接狀態表中；客戶端啟動一個單獨的線程,用來接收服務器發過來的消息；服務端會定期發送心跳包給客戶端。

圖1　服務構架

當客戶端A給客戶端B推送消息時,服務器會解析該消息,根據客戶端B的ID查找客戶端B的文件描述符,并判斷客戶端B的連接狀態,若客戶端B已連接,則對其推送,如果未連接,則將推送消息正文插入到延遲推送消息表內,而當客戶端出現網絡異常,或者程序出錯,則服務器會修改其連接狀態。

高性能程序設計結構如圖2所示,由圖2可知，該服務有2個線程池(讀消息線程池和發送消息線程池)、1個消息備份線程(異步備份消息)、1個日志線程(異步記錄日志)、1個句柄池、1個消息任務池、1個日志任務池。

圖2　程序結構

當客戶端A向客戶端B發送消息時,主線程接收其句柄(即文件描述符),將其放入句柄池。讀消息線程池從句柄池中取出句柄,讀消息并對其解析,將解析出來的消息放入消息任務池。發送消息線程池,從消息任務池中取消息,然后根據推送目標ID及其連接狀態,對其進行消息推送或者消息延遲處理。消息備份線程則根據消息任務池中的消息對其進行備份,日志線程記錄程序中各種異常情況信息。

3.2Epoll-MP數據庫表結構

本文在實現Epoll-MP時,主要采用連接信息表、推送消息備份表和推送消息延遲表。

連接狀態表記錄了手機登錄ID、組播號、文件描述符及連接狀態,通過該表鏈決定推送目標,以及根據連接狀態確定是否要延遲推送消息,連接狀態表結構如下：

CREATE TABLE ′PushBlockMsg′(

′id′int(11)NOT NULL AUTO_INCREMENT,

′client_id′varchar(32)DEFAULT NULL COMMENT ′客戶ID′,

′msgsize′int(11)DEFAULT NULL,

′blockmsg′varchar(1536)DEFAULT NULL COMMENT ′阻塞重傳消息′,

′msg_time′datetime DEFAULT NULL,

′remark′varchar(1024)DEFAULT NULL,

PRIMARY KEY(′id′)

)ENGINE=MyISAM AUTO_INCREMENT=25 DEFAULT CHARSET=latin1.

延遲推送表主要記錄了未推送成功的消息,以便推送目標上線后對其推送,延遲推送表結構如下：

CREATE TABLE ′PushConnectInfo′(

′client_id′varchar(32)CHARACTER SET utf8 NOT NULL COMMENT ′用戶登錄ID′,

′group_id′varchar(32)CHARACTER SET utf8 DEFAULT NULL COMMENT ′用戶所在的群組′,

′client_fd′int(11)DEFAULT NULL COMMENT ′用戶連接句柄′,

′flag′int(11)DEFAULT NULL COMMENT ′連接狀態：0—未連接，1—連接′,

′last_connect_time′datetime DEFAULT NULL COMMENT ′上次成功連接的時間′,

′remark′varchar(1024)CHARACTER SET utf8 DEFAULT NULL COMMENT ′注釋′,

PRIMARY KEY(′client_id′)

)ENGINE=MyISAM DEFAULT CHARSET=latin1.

消息備份表主要是對消息進行一個備份,具體如下：

CREATE TABLE ′PushMsgSave′(

′id′int(11)NOT NULL AUTO_INCREMENT,

′SrouceId′varchar(32)CHARACTER SET utf8 DEFAULT NULL COMMENT ′推送消息發送方′,

′ObjId′varchar(32)CHARACTER SET utf8 DEFAULT NULL COMMENT ′推送消息接收方′,

′ObjId_type′int(11)DEFAULT NULL COMMENT ′推送方類型 1—個人，2—組′,

′msg′varchar(32)CHARACTER SET utf8 DEFAULT NULL COMMENT ′消息′,

′msg_time′datetime DEFAULT NULL COMMENT ′時間′,

′remark′varchar(1024)CHARACTER SET utf8 DEFAULT NULL,

PRIMARY KEY(′id′)

)ENGINE=MyISAM AUTO_INCREMENT=1983 DEFAULT CHARSET=latin1.

3.3Epoll-MP數據包結構

本方法采用TCP長連接的通信方式,但是在發送包的過程中會存在粘包問題。為了解決粘包問題,對數據包進行定義,發送消息由包頭和包體組成，具體定義如下。

包頭:4個字節表明包體長度。

包體:json串格式發送,下面給出字段。

ProType:處理類型有1—連接、2—點對點消息、3—點對多消息。

SelfId:該客戶端本身的ID號,即app登錄號。

GroupId:連接時,為自己本身組號;推送時為目標組號。

ObjId:推送信息目標ID。

PushMsg:推送信息內容[UrlCode編碼]。

MsgSize:推送內容大小。

具體實例如下:

0108