Staged Event Driven Architecture (SEDA) 介绍

作者：朱之光

http://larryzhu.bokee.com

一、前言

二、当前流行的两种并发处理编程模型

三、SEDA架构

四、小结

五、参考文献

一、前言

Staged Event Driven Architecture (SEDA) 是加州大学伯克利分校研究的一套优秀的高性能互联网服务器架构模型。其设计目标是：支持大规模并发处理、简化系统开发、支持处理监测、支持系统资源管理。本文会先对两种目前被广泛使用的网络服务器架构模型进行介绍。然后对SEDA进行详细描述。

二、当前流行的两种并发处理编程模型

1、 多线程服务器 (Threaded Server)

工作原理：对于每一个request，dispatcher会为其创建并分配一个线程。该线程负责这个请求的处理。这种方式 又名（Thread-per-request）。

优点：执行粒度是整个完整的处理流程。处理逻辑清晰，容易开发。

缺点：是当随着处理请求不断增加，导致并发执行的线程数量太多。过多的线程数量导致系统在线程调度和资源争用上的开销过大。引起系统性能急剧下降。导致系统处理能力下降。

改进措施：线程池（Bounded Thread Pools）

系统最多只能创建一定数量的线程。当所有线程都饱和运行时，新到达的处理请求只能等待，或者被抛弃。

缺点：

执行粒度仍然是完整的处理流程。难以检测系统性能瓶颈的根源以及进行相应调整。/p>

2、 事件驱动并发处理(Event-Driven Concurrency)

将处理流程分割成多个步骤，每一个步骤都实现为一个有限状态机（FSM）。

工作原理：所有的处理请求会作为Event进入系统。由Scheduler负责传递给相应FSM。FSM的处理结果也以Event形式输出给Scheduler。新的Event会再次被Scheduler进行转发给下一个FSM。直至处理完成。

优点：

1、随着处理量的增加，系统负荷是以线形增长。当达到系统饱和处理能力后。系统的处理能力不会下降。

2、由于将各个处理步骤独立实现，可以很容易的进行系统监测和调整。

缺点：

Scheduler的设计和实现过于复杂。针对于不同的应用和系统的逻辑变更需要不同的实现。

三、SEDA架构

(近似于Event-Driven Concurrency，但是没有其中的Scheduler)

将每一个处理步骤独立为一个Stage。

Stage结构：

1、 一个接受输入的Event Queue；

2、 一个应用开发者编写的Event Handler；

3、 一个Controller用于对执行过程进行控制。包括并发线程数量，批处理数量，…;

4、 一个Thread Pool用于并发处理；

Stage的输入通过Event Queue获得。Stage的输出会以Event形式推送到其他Stage的Event Queue中。Stage之间的这种连接关系由应用开发人员指定。

带来的问题：Event Queue尽管减少了模块间的耦合性，但是会降低响应速度。

四、小结：

SEDA架构将应用的整个处理过程分割为多个步骤即Stage。每个Stage可以独立进行开发。同时Stage之间通过Event Queue来进行通信，可以降低耦合性。可以以很小的成本来适应将来的系统逻辑变化。

同时系统提供了标准的资源控制，使得应用开发人员只需要专注于实现Event Handler的内部逻辑。而无须关注多线程、资源共享、…

同时可以在运行时对于每一个Stage的运行情况进行监测以及调整。

五、参考文献：http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf