[fwd]SEDA简介

1.Overview

* SEDA
* An Architecture for Highly Concurrent,Well-Conditioned Internet Services
* Adaptive Overload Control for Busy Internet Servers

SEDA是NIO的重要input，但SEDA框架本身已不再发展。
它的核心思想是把一个请求处理过程分成几个阶段，不同资源消耗的阶段使用不同数量的线程来处理，阶段间使用事件驱动的异步通信模式。

SEDA要求每个Stage需要

* 动态配置自己的线程数
* 在超载时降级运行，如输出纯文字页面
* 在超载时拒绝接收服务

因此每个SEDA的Stage的结构通常有如下组件

* Incoming Event Queue ，事件队列。
* Admission Controller 阀门，拒绝服务。
* Dynamically sized Thread Pool 线程池。
* Event Handler 实际处理业务的Compinent。
* Resource Controller 控制Stage的参数。

2.Web2.0+SOA环境下的SEDA应用

Java EE 迎合 Web 2.0(IBM DW) web2.0虽然最重要的还是策划者的点子，但架构师在Web2.0大潮里也不再无所事事了 因为：
2.1 问题

1.在Web2.0+SOA里，系统越来越多的调用外系统，mashup的应用更需要从外系统pull大量data。
外系统的调用直线增加了任务的时长。cache是一个常用方法，但对一些query result或实时信息较为无力。
而且Web Service调用的时间主要时间花在建立连接与传输数据上，对服务处理的CPU时间花费不大，对服务代码的优化成果不大。
长连接是更有效的方法(比如Ajax的Comet)，但要求服务端有高效的处理模型。

2. 在Web2.0里，用户获得了更多的交互动作，会比Web1.0发起更多的请求，尤其是Ajax的大量运用，显示一个页面需要更多的连接交互。

3. 页面的长度也在内容丰富中膨胀。而且页面的数量也因为用户的直接参与创建而疯狂增长。

4. 峰值效应。如果你的网站被某知名网媒头条推荐(如一个著名的新闻站，博客站，社区)，可能会在短时间内迎来一个完全超出平时设计容量的访问洪峰。网媒的发达使洪峰发生的概率要远高于1.0时代。

JavaEE 的同步调用机制(除JMS)，有限的线程池与连接池(超出范围性能会下降)，固定的定义在JNDI的资源对Web2.0/SOA的需求并不吻合。对BEEP，SCTP这些协议，必须依靠JCA另行编写模块来实现长连接模型。

2.2 SEDA的解决方案

从统计学上看，在系统总线程数固定的情况下，使用SEDA能获得较高的Throughput，阶段间的资源差异越大就越明显。
比如处理一个Web 2.0常用请求，有如下几步

1. 接收用户请求(1单位时间)
2. 数据库查询(4单位时间)
3. 根据数据库查询结果，准备Web Service调用参数(1单位时间)
4. 发起Web Service调用((16单位时间))
5. 将结果渲染返回给用户(2单位时间)


那么SEDA会使用一条线程处理1.接收用户请求、3.准备WebService、5.返回结果，两条线程处理数据库查询， 而5条线程处理耗时最多的WebService请求。
而且结果表明，当远程调用所花时间不变，而本地操作得到优化时，系统通量也能获得明显提高。

3. SEDA 实例

* Mule
* MINA