SEDA基于步骤的事件驱动架构将事件处理和线程调度解耦，并提供动态负载管理。
SEDA combines aspects of threads and event-based program-ming models to manage the concurrency, I/O, scheduling, and resource
management needs of Internet services.
SEDA decomposes an application into a network of stages separated
by event queues and introduces the notion of dynamic resource con-trollers to allow applications to adjust dynamically to changing load.
传统一个请求一个线程处理的模型，容易在并发过高的时候让系统产生雪崩效应，而SEDA则可以按照步骤控制每一个步骤的并发处理数，当并发饱和的时候，直接把请求阻塞，服务降级，让系统的处理能力吞吐量维持在一个常量上，不会有雪崩效应。
http://www.eecs.harvard.edu/~mdw/proj/seda/
A stage is a self-contained application component consisting of an event han-dler, an incoming event queue, and a thread pool。
Stage threads operate by pulling a batch of events off of the incoming event queue and invok-ing the application-supplied event handler. The event handler processes each batch of events, and dispatches zero or more events by enqueuing them on the event queues of other stages.
A SEDA application is constructed as a network of stages, connected by
event queues
从统计学上看在系统总线程数固定的情况下，使用SEDA能获得较高的Throughput，阶段间的资源差异越大就越明显。这个是seda架构的理论依据。
很生动形象的介绍，关于seda，有时间实践一把。
http://www.360doc.com/content/12/0529/22/9579107_214610796.shtml
http://xiaoy.iteye.com/blog/432134
理解seda，可以从最佳线程池数量计算公式入手（原理是以最少的线程数量充分利用cpu资源，不要让cpu闲下来）。一个系统的多个请求流过不同的stage，不同的请求需要的线程池线程数量不一样。
如果一刀切的话，势必会造成资源调配不一。所以需要对系统的不同处理组件划分不同的stage，不同的stage根据自身是st和wt的比例采用不同的线程池模型。
http://www.iteye.com/topic/149826
http://www.iteye.com/topic/91908
实验：请求A 经历P1-1：5，P2-1:10 请求B经历 P1-1:5，P3-1:30,，按照采用同一个线程池计算最优线程数量为19*2（双核），
采用SEDA，三个线程池处理P1\P2\P3，分别线程池大小是12*2,22*2,62*2。
处理请求数 传统方式处理时间 seda处理时间
50 14609 10922
100 25532 21078
200 48250 41687
400 89797 82438