SEDA的是上演事件驱动架构的缩写，一个复杂的，事件驱动的应用程序分解成一组队列连接的阶段 。 这种设计避免了与基于线程的并发模型相关的开销，并分离事件和应用程序逻辑线程调度。 通过执行每个事件队列入场控制，服务以及空调加载，防止资源被过度，当需求超过服务能力。  SEDA的采用动态控制，自动调节运行参数（如每个阶段的调度参数），以及管理负载，例如执行自适应负载脱落。 分解成一阶段的服务，也使复杂的事件驱动应用程序的模块化和代码重用，以及调试工具的发展。

对于服务端端处理模型，目前广泛使用的有两种：

1、多线程处理模型。这种模型由一个主线程和多个work线程构成，主线程负责接收请求，并将接收到的请求分发给合适的work线程处理，work线程处理完请求后直接将响应返回给客户端。这种模型很简单，也有着广泛的应用，尤其是通常的后端模块，处理逻辑在work线程里是阻塞进行的。这个模型的 缺点也很明显，如果大量的work线程因为某种原因被堵住（比如连接的DB响应太慢、从磁盘获取文件数据等），将使得后续的请求得不到处理，而最经典的例 子莫不过apache了。

2、事件驱动（Event-Driven）处理模型。这种模型克服了多线程模型的并发量缺点，对请求采用事件驱动方式处理，这里的事件通常是IO事 件，其底层的实现依赖于非阻塞IO和IO多路复用。事件驱动模型很适合于IO密集型的应用，这种应用对CPU消耗代价甚至要小于线程间的切换代价，比如各 种proxy。而现在的proxy，基本都标配Epoll，使得能支持的并发请求数在万级别。像lightty、nginx，是事件驱动模型的经典应用， 请求的处理流程是由状态机驱动的，每次状态的切换经由一次事件触发，这样单线程就够用了（当然，如果需要支持更高的处理能力，可以采用多进程的事件驱动模 型）。事件驱动的缺点在于：1）单个处理阶段不能阻塞太长，如果有这方面的问题，一般可采用专门的线程处理，处理完了再触发事件让主线程接着处理。2）整 个事件驱动流程通常是固定的，在一个线程内由调度器完成，这使得它很难做的通用，使应用可以自定义流程。

基于上面提到的两种模型的优缺点，SEDA被提出来，它的核心思路是：一个请求被分成多个stage进行处理，每个stage彼此间独立，一个请求 的多个stage可以串行化也可以并行化。stage内部使用Event-Driven，新到的请求放到event queue中，系统从thread  pool中的选择一个线程经由Event Handler处理，Event  Handler处理完后将请求派发到下一个stage。

1）输入的event queue。SEDA中的event queue的大小是有限制的。所以，如果event queue 达到阈值，新到的event可能会被拒绝或者转发到特定的stage（比如错误处理stage）。

2）thread pool：这个线程池对应用是透明的，并且每个stage的线程池是彼此独立的。针对请求量及特点，线程池可以动态的调整大小，不至于某个stage的线程池耗尽所有的资源。

3）event handler，event handler接收系统给予的event，做具体的逻辑处理后将event分发到其他stage。event handler通常需要应用开发者编写。