Staged Event Driven Architecture (SEDA) 介绍

一、前言

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

三、 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

 

http://larryzhu.bokee.com/6779982.html