EventMachine的性能研究及應(yīng)用

李德寬

近年來(lái)使用Ruby語(yǔ)言來(lái)開(kāi)發(fā)監(jiān)控告警模塊也越來(lái)越頻繁，監(jiān)控告警模塊需要極高非阻塞和并發(fā)事件處理能力，然Ruby語(yǔ)言自身對(duì)非阻塞操作的支持不多。使用EM可以解決請(qǐng)求易阻塞和并發(fā)事件處理能力不強(qiáng)等問(wèn)題。本文對(duì)EM的并發(fā)性能以及網(wǎng)絡(luò)性能進(jìn)行研究和分析。此外，本文還將對(duì)EM在網(wǎng)絡(luò)編程方面的能力進(jìn)行研究。通過(guò)這些研究表明EM具有極高非阻塞和并發(fā)事件處理能力以及強(qiáng)大的網(wǎng)絡(luò)性能。

【關(guān)鍵詞】Ruby EventMachine 非阻塞 高并發(fā) 網(wǎng)絡(luò)協(xié)議

Ruby語(yǔ)言是一種為簡(jiǎn)單快捷的面向?qū)ο缶幊潭鴦?chuàng)立的腳本語(yǔ)言，于20世紀(jì)90年代由日本人松本行弘開(kāi)發(fā)。Ruby on Rails（簡(jiǎn)稱 Rails）基于Ruby語(yǔ)言編寫的一個(gè)通用高效Web開(kāi)發(fā)框架，由于其部署容易、開(kāi)發(fā)效率高、功能豐富、包管理便捷等特點(diǎn)，使用 Rails 開(kāi)發(fā)的 Web 項(xiàng)目日漸增多。

1 EM的實(shí)現(xiàn)原理

EM廣義上來(lái)講是指任何采用EM事件處理機(jī)制的這類程序包或程序?qū)崿F(xiàn)，而這里的EM特指的是基于Ruby實(shí)現(xiàn)的支持EM機(jī)制的Ruby 類庫(kù)，它使用Reactor模式提供事件驅(qū)動(dòng)下的非阻塞IO，下面將從其本身的Reactor模式以及Event Loop進(jìn)行分析，并闡述其實(shí)際應(yīng)用中起到的作用。

1.1 Reactor模式簡(jiǎn)述

Reactor模式描述了一種服務(wù)處理器，它接受各種類型的抽象事件并將這些事件分發(fā)給已注冊(cè)的事件處理器進(jìn)行處理。Reactor模式會(huì)直接的并行將請(qǐng)求根據(jù)類型分發(fā)給對(duì)應(yīng)的事件處理器，而不是同步等待每個(gè)請(qǐng)求執(zhí)行完成。這種模式清晰的分離了事件的分發(fā)時(shí)序和事件的處理邏輯。

基于以上的分析，我們可以推論出EM本身是支持并發(fā)處理的。

1.2 Event Loop簡(jiǎn)述

EM模型基于事件輪詢（Event-Loop）機(jī)制，Event Loop的機(jī)制在EM中體現(xiàn)為Dispatcher和Event Handle的配合。

為了理解Event Loop的工作機(jī)制，可以先從單線程程序的時(shí)間處理運(yùn)行模式入手。多線程的程序不僅會(huì)占用多倍的系統(tǒng)資源，還會(huì)遇到跨線程通信、多線程對(duì)同一個(gè)變量同時(shí)操作等等的問(wèn)題，這樣顯然無(wú)法在保障系統(tǒng)的穩(wěn)定性的同時(shí)確保系統(tǒng)的擴(kuò)展性。而Event Loop就是為了解決這個(gè)問(wèn)題而提出。

每當(dāng)遇到I/O請(qǐng)求的時(shí)候，主線程令Event Loop線程調(diào)相應(yīng)的I/O程序，然后接著往后運(yùn)行，所以不存在等待時(shí)間。等到I/O程序完成操作，Event Loop線程再把結(jié)果返回主線程。主線程就調(diào)用事先設(shè)定的回調(diào)函數(shù)，完成整個(gè)任務(wù)。

因此線程的可用空閑時(shí)間增加，主線程得以運(yùn)行更多的任務(wù)，提高了效率。這樣就實(shí)現(xiàn)了非堵塞模式。

2 Event Machine在網(wǎng)絡(luò)編程中的應(yīng)用

2.1 EM搭建TCP的案例來(lái)源

前面我們闡述了EM的Event Loop的優(yōu)勢(shì)?，F(xiàn)在，我們就通過(guò)實(shí)際案例來(lái)實(shí)踐EM搭建TCP，并且進(jìn)行相應(yīng)的業(yè)務(wù)處理。

我們知道，在生活中有很多傳感設(shè)備分布在身邊的各個(gè)角落，這些傳感設(shè)備無(wú)時(shí)無(wú)刻不在測(cè)量和傳輸新鮮出爐的測(cè)量數(shù)據(jù)，這些數(shù)據(jù)都亟待保存，因?yàn)閭鞲衅鹘^對(duì)沒(méi)有空間去存儲(chǔ)這些數(shù)據(jù)。

那么，面對(duì)這樣的大規(guī)模，高并發(fā)的數(shù)據(jù)，我們應(yīng)該怎樣應(yīng)對(duì)，讓它平穩(wěn)的運(yùn)行在系統(tǒng)管控之下呢？我們可以用到我們的EM來(lái)搭建TCP服務(wù)器解決這個(gè)問(wèn)題。

2.2 信息流程分析

信息源，就是我們分布在各個(gè)角落的信息化監(jiān)控設(shè)備。

傳輸?shù)男诺?，就是開(kāi)放的空間。在集成的蜂窩通信協(xié)議的基礎(chǔ)上，這些硬件大多集成了基礎(chǔ)的分組數(shù)據(jù)傳輸協(xié)議，在分組數(shù)據(jù)傳輸協(xié)議上面又封裝了TCP/IP協(xié)議的支持。

接收的設(shè)備，就是我們的服務(wù)器。

信息源將傳感器部件采集到的數(shù)據(jù)收集到一起，按照一定的規(guī)則拼接組合起來(lái)，形成原始數(shù)據(jù)。為了保證傳輸?shù)陌踩?，這些數(shù)據(jù)會(huì)被加上循環(huán)校驗(yàn)碼和長(zhǎng)度信息，在發(fā)送前，這個(gè)信息會(huì)被封入TCP的數(shù)據(jù)包，傳輸出去。

傳輸過(guò)程中，因?yàn)橥ㄟ^(guò)的鏈路可能存在差異，所以數(shù)據(jù)到達(dá)服務(wù)器的時(shí)間順序不一定一致。極有可能出現(xiàn)順序靠前的數(shù)據(jù)后到，而順序靠后的數(shù)據(jù)先到的情況。當(dāng)然，這個(gè)已經(jīng)由TCP協(xié)議的系統(tǒng)實(shí)現(xiàn)來(lái)為我們進(jìn)行了處理。

接收到通過(guò)TCP協(xié)議傳輸來(lái)的數(shù)據(jù)的時(shí)候。服務(wù)端會(huì)將接收到的數(shù)據(jù)分配到注冊(cè)的處理器進(jìn)行處理。如下的一小段代碼，就是向分配器注冊(cè)事件處理對(duì)象。

EM.run do

EM.start_server 127.0.0.1， ‘8089， EchoServer

end

我們可以看到，這段代碼向系統(tǒng)注冊(cè)了監(jiān)聽(tīng)器，監(jiān)聽(tīng)發(fā)向IP地址為“127.0.0.1”，目標(biāo)端口為“8089”的數(shù)據(jù)響應(yīng)。響應(yīng)數(shù)據(jù)到達(dá)事件的處理程序，就是EchoServer這個(gè)對(duì)象。

進(jìn)一步的深入EchoServer對(duì)象，我們可以發(fā)現(xiàn)它的基本結(jié)構(gòu)遵循這樣的規(guī)則：

一定有post_init和receive_data這兩個(gè)接口。

這種設(shè)計(jì)模式，確保了負(fù)責(zé)處理的程序的充分自主性。處理事件的程序只需要確保實(shí)現(xiàn)這兩個(gè)接口，就可以接入到EM的Event Loop中，接收屬于自己的事件。

一個(gè)EM實(shí)現(xiàn)的基本框圖如下所示。

EM處理主事件循環(huán)，如果有事件出現(xiàn)（例如呼入請(qǐng)求），EM將根據(jù)已注冊(cè)的事件處理程序?qū)κ录M(jìn)行分發(fā)，交由注冊(cè)的程序進(jìn)行處理，如果是未注冊(cè)的請(qǐng)求事件，則EM會(huì)將它們拋棄，不予處理。

3 結(jié)論

本論文給出了一種解決Ruby語(yǔ)言在監(jiān)控告警模塊中自身對(duì)非阻塞操作支持不多的方法EM，并通過(guò)對(duì)EM中Event Loop的研究，發(fā)現(xiàn)EM能夠提供非阻塞 IO 的支持。

在網(wǎng)絡(luò)應(yīng)用方面，通過(guò)EM搭建TCP協(xié)議作為例子，EM能夠廣泛地支持各種網(wǎng)絡(luò)協(xié)議。相對(duì)于傳統(tǒng)的網(wǎng)絡(luò)協(xié)議，在面對(duì)這大規(guī)模、高并發(fā)的數(shù)據(jù)時(shí)，我們的EM搭建TCP的服務(wù)器可以使數(shù)據(jù)平穩(wěn)的運(yùn)行在系統(tǒng)管控之下。

作者單位

武漢理工大學(xué)信息工程學(xué)院電子與通信工程 湖北省武漢市 430070