CloudFoundry中EventMachine的初步学习

为什么我们需要EventMachine？

我们通常说的Ruby解释器里的Ruby线程是Green Thread：即程序里面的线程不会真正映射到操作系统的线程，而是由语言运行平台自身来调度，并且这种线程的调度不是并行的。

关于Ruby的并发问题这里有一个权威的解释：http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby

这篇文章提到造成这种情况的原因主要是由于Ruby解释器和VM中GIL（Global Interpreter Lock，如下图所示）的存在，使得Ruby始终无法真正的享受多核带来的好处，尽管在Ruby1.9的解释器已经能够使用多个系统级别的线程，但是GIL为了保证我们代码的线程安全，只允许同一时刻运行一个单一的线程。当然，事情并不是绝对的，下图最右的JRuby则把线程调度的工作交给了JVM从而实现任务的并发执行。

所以，基于Ruby的复杂应用大多采用了这样的一种策略：使用推迟（defer）并发（parallelize）的方法来处理程序中的网络I/O部分，而不是引入线程到应用程序中。

EventMachine 就是一个基于Reactor设计模式的、用于网络编程和并发编程的框架。Reactor模式描述了一种服务处理器——它接受事件并将其分发给已注册的事件处理。这种模式的好处就是清晰的分离了时间分发和处理事件的应用程序逻辑，而不需引入多线程来把代码复杂化。

EventMachine 本身提供了操作方便的网络套接字和隐藏底层操作的编程接口，这使得EM在CloudFoundry中被广泛的使用着。接下来，我们将对其机制进行一个简单的说明。

Reactor Pattern

“The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.”——wiki

p.s. 这样的工作方式有些类似于Observer Pattern，但后者只监听一个固定主题的消息。

上述定义可以用下面的图示来描述，其中灰色的部分就是Reactor：

Demultiplexer：是单进程阻塞式的主事件循环（event loop）。只要它没有被阻塞，它就能够将请求交给event dispatcher。

Dispatcher：负责event handler的注册和取消注册，并将来自Demultiplexer的请求交给关联的event handler。

Event handler：是最终处理请求的部分。

1、一个最简单基于EM的HttpServer的例子

在另一个窗口，输入hello，服务器返回hello：

仔细看一下上面的程式：EM帮我们启动了一个server，监听端口10000，而Echo实例（继承了Connection，用来处理连接）则重写了receive_data方法来实现服务逻辑。

而EM.run实际上就是启动了Reactor，它会一直运行下去直到stop被调用之后EM#run之后的代码才会被执行到。Echo类的实例实际上是与一个File Descriptor注册在了一起（Linux把一切设备都视作文件，包括socket），一旦该fd上有事件发生，Echo的实例就会被调用来处理相应事件。

在CloudFoundry中，组件的启动大多是从EM.run开始的，并且出于在多路复用I/O操作时提高效率和资源利用率的考虑，CF组件往往会在EM.run之前先调用EM.epoll （EM默认使用的select调用），比如：

2、EM定时器（Timer）

EM中有两种定时器，add_timer添加的是一次性定时器，add_periodic_timer添加的是周期性定时器。

细节：我们在第一个EM:eriodicTimer代码块中，传入了另外一个代码块：puts “Tick”。这里实际上告诉了 EM 每隔1秒触发一个事件，然后才调用puts代码块，这里的puts代码块就是回调。

3、推迟和并发处理

EM#defer和EM#next_tick发挥作用的地方分别是：1、长任务应该放到后台运行；2、一旦这些任务被转移到后台，Reactor能够立刻回来工作。。

EM#defer方法

负责把一个代码块（block）调度到EM的线程池中执行（这里固定提供了20个线程），而defer的Callback参数指定的方法将会在主线程（即Reactor线程）中执行，并接收后台线程的返回值作为Callback块的参数。

执行示意图如下：

EM#defer+Callback的用法：

EM#next_tick方法

负责将一个代码块调度到Reactor的下一次迭代中执行，执行任务的是Reactor主线程。所以，next_tick部分的代码不会立刻执行到，具体的调度是由EM完成的。

这里Reactor执行的过程用是同步的，所以太长的Reactor任务会长时间阻塞Reactor进程。EventMachine中有一个最基本原则我们必须记住：Never block the Reactor!

正是由于上述原因，next_tick的一个很常见的用法是递归的调用方式，将一个长的任务分配到Reactor的不同迭代周期去执行。

正常的循环代码：

使用next_tick来处理:

next_tick中的block执行如红色的Task 1所示：

如上图所示那样，next_tick使单进程的Reactor给其他任务运行的机会——我们不想阻塞住Reactor，但我们也不愿引入Ruby线程，所以才有了这种方法。

next_tick在CloudFoundry中应用非常广泛，比如下面Router启动的一部分代码：

与next_tick同样作用的方法还有EM.schedule，后者会不停地判断当前线程是不是Reactor线程。

next_tick还有个用处：当你通过defer方法把一个代码端调度到线程池中执行，然后又需要在主线程中使用EM::HttpClient来发一个出站连接，这时你就可以在前面的代码段里使用next_tick创建这个连接。

4、EM提供的轻量级的并发机制

EvenMachine内置了两钟轻量级的并发处理机制：Deferrables和SpawnedProcesses。

EM:deferrable

如果在一个类中include了EM:deferrable，就可以把Callback和Errback关联到这个类的实例。

一旦执行条件被触发，Callback和Errback会按照与实例关联的顺序执行起来。

对应实例的#set_deferred_status方法就用来负责触发机制：

当该方法的参数是:succeeded，则触发callbacks；而如果参数是:failed，则触发errbacks。触发之后，这些回调将会在主线程立即得到执行。当然你还可以在回调中(callbacks和errbacks)再次调用#set_deferred_status，改变状态。

EM::SpawnedProcess

这个方法的设计思想是：允许我们创建一个进程，把一个代码段绑定到这个进程上。然后我们就可以在某个时刻，让spawned实例被#notify方法触发，从而执行关联好的代码段。

它与Deferrable的不同之处就在于，这个block并不会立刻被执行到。

注意这两种机制的使用方式是不一样的：一个是作为内部类include进去进而使用其定义的callback来执行的；而另一个是直接使用spawn实例通过notify来触发代码块来执行的。

5、使用EM简化网络编程

网络编程的简单化是ＥＭ的一大特色。拿前面的Echo举例子，我们通过十分简洁的代码就可以实现一个HttpServer的功能。

我们其实还有更简洁的方式来完成这个工作，比如使用module：

以及直接使用block：

事实上，每次你新建一个连接，一个新的包含了你代码的匿名类就会被创建。理论上，不同的连接不能互相交换信息，这一点很重要。不过EM实际上在设计时以及解决这个问题：

通过给start_server添加一个块，EM会把把Pass的实例传进去（这个操作发生时实例已经被初始化但是客户端数据还没收到）。这样我们可以用这种方法为每个实例set值。

下面我们使用EventMachine建立一个客户端，这是非常简单的事情：

除了使用EM#connect之外，客户端同服务器端的代码是一样的。其实EM::Connection类中还有很多有用的方法等着你实现：

post_init 当实例创建好，连接还没有完全建立的时候调用。一般用来做初始化
connection_completed 连接完全建立好的时候调用
receive_data(data) 当收到另一端的数据时调用。数据是成块接收的
unbind 当客户端断开连接的时候调用

此外，还有#close_connection#close_connection_after_writing这两个方法供用户断开连接。

下面给出一个更完整的例子，设置最大连接次数：