Web Server 架构浅谈-Staged Event-Driven Achitecture(SEDA)

原文地址：http://blog.csdn.net/pennyliang/article/details/5940666

Web Server 架构浅谈-Staged Event-Driven Achitecture(SEDA)

回顾我们上节讨论的 单进程的简单事件驱动架构，我们一起来做个简要的评价：

   

	公平性	响应时间	吞吐率	CPI	缓存命中率	开发难易程度	可维护性
简单事件驱动架构	高	长	低	高	低	易	高

   

    单进程的事件驱动架构在资源利用率，缓存命中率，响应时间均不理想，主要有几个原因： 1）处理一个请求可能有多个上下文，因此依次响应用户请求就会在这些上下文上反复切换，程序的局部性不强。2）资源的有序使用导致了闲置，例如在等待读盘的时候，CPU闲置。针对这两个问题，结合多线程的特点，产生了分阶段的事件驱动的架构(Staged Event-Driven Architecture)和多流水线的分阶段事件驱动架构。
 
    分阶段的事件驱动架构：
    在处理一个复杂任务时，往往需要很多工序，以某工厂流水线的工序为例，第一步：把螺丝钉部分锤入模板，第二步：把螺丝钉继续旋进木板，第三步：把木板的四角锯掉。如果1个工人来处理这三步的话，则需要在锤子，螺丝起和锯子三种工具上进行切换，并且要掌握三种技术，这显然是非常吃力的。如果有3个人，每个人都具有这种能力，流水线的流动速度也会有限。但假如这三个人分别拿着锤子，螺丝起和锯子，分别做三个工序，速度可以大大加快，并且由于这三个人术业专精可以分别优化。

    因此分阶段的事件驱动架构就是在利用事件驱动架构的基础上，将多线程的每个线程包办全部工作，拆分成线程只处理一小块任务，线程的计算和空间局部性就会大大提高。分阶段的事件驱动架构如下图：
  

   

      上图是一个分两段的事件驱动架构，也是单条流水线架构。一个大的处理被分解成两个局部性强的计算阶段，在阶段内采用线程池充分发挥对资源的使用。跨阶段采用队列进行任务传递，由最后一个任务来对用户请求做最后回复。这种拆分成流水线的架构的扩展性很强，可以将不同的阶段处理放在不同的服务器上。

 流水线的设计需要注意这样几点：
（1） 阶段的复杂性应大致一致
从流水线理论上讲，每个阶段的处理时间相同是最佳的，如果某个阶段处理时间太长，就会出现后面的阶段饥饿，前面的阶段堵塞。
 
（2） 阶段的划分尽可能从资源的角度出发
例如第一阶段分词，只使用分词词典，第二阶段分类，只使用分类树，第三阶段决策，只使用决策树。阶段间不发生资源争用，资源只在阶段内共享。
 
（3） 阶段的划分需要考虑剪枝
传统的工艺流水线，通常会把破坏性强的工序提前，因为一旦出现次品就直接丢弃，后面的工作就省了，例如一次搜索结果的处理有这样三个工序，垃圾网页去除，死链去除，重复网页去除。假定这三个工序的复杂性依次提高，那么显然应该先过滤垃圾网页，将搜索结果数大大减少，丢掉的网页不再进行下面的计算。
（4） 阶段的优化需要同步
往往一个阶段过渡优化，在整条流失线上很难看出效果，需要对短板进行优化，并避免过渡优化。

 

      多流水线的架构在此基础上进一步改进，相当于多个运行的实例，以求得对资源的最大利用。进一步提高对资源的饱和使用状况。这种流水线的架构也是业绩比较推崇的，在各方面指标上都比较理想。

    下一节我们见讨论流水线架构的一些评价，另外给出目前已有的一些web server架构，例如Cappriccio等。待续

 

       整个流失线的架构有一环没有涉及就是lock-free的queue，如果要讨论这个会比较大，可能有得花一个系列，不知道读者朋友们是否有兴趣，如果大家都比较了解了，我就不打算写了。

 

      本系列暂告一个段落，既往内容可参见

    

(3)Web Server 架构浅谈-Simple Event-Driven Achitecture（也称SPED，single-processed event driven）

(2)Web Server 架构浅谈-Threadpool-based Multiple Threaded Achitecture

 

(1)Web Server 架构浅谈-Simple Multiple Threaded Achitecture