闲聊SEDA分段式事件驱动架构

SEDA是10年前提出的一个理论
目的是实现高性能的网络服务器


由7篇论文和一个参考实现的库组成
都在这里 http://www.eecs.harvard.edu/~mdw/proj/seda/
有兴趣的自己去看
在SEDA提出之前，
网络服务器的模型发展经历过两个阶段


第一个是每访问每线程模式
每个访问进来，都新起一个线程为其服务
比如servlet之类的处理模式


我们也可以很简易的自己花100行代码，写个简单的静态httpserver
处理完了情况，线程销毁掉
下次有请求，再创建
访问量大了，线程数急速增大


而且新建和销毁也很频繁
导致系统本身消耗太大
为了解决这个问题，
线程复用的技术就出现了
这就是线程池


请求进来以后，不是新建线程处理
而是从线程池中获取一个空闲的线程来处理
访问量大了以后，所有的线程都在忙


新来的访问，就排队等待或者丢弃
线程池的模型就出来了
一组线程、一个队列、一个丢弃策略


这个模型比第一个来，可以说是质的飞跃
无论是效率还是稳定性
但是，我们都知道，
服务器基本上是一个通用设施，对于不同的请求，不同的处理，


其处理特点是不一样的
而且，对网络服务器来说，后端的业务处理可能很慢
这是，线程就会被占用，很长时间无法释放


比如一只在等待一个block住的本地io，之类的操作
线程一直在空转
如果丢回线程池，
给别的任务复用
性能将会有进一步的提升


并且极大提升了系统的整体吞吐量
这个就是SEDA的思想
更小粒度的复用资源
具体的做法就是stage
分段处理


前端的网络接入，中间的服务器web处理，后端的业务处理，或者还有其他的处理，
分成多个段。
各段之间都是独立的处理单元
都是一个前面提到的模式：一组线程、一个队列、一个丢弃策略


这样，web处理的线程就不会被后端很慢的业务处理线程阻塞
web服务了一个请求，丢给后端业务处理以后
直接再处理下一个请求即可


业务处理线程完成以后，通过事件通知web处理层
web处理线程，再返回给调用方
这就是事件驱动
整个流程就是SEDA


分段式，事件驱动，架构


通过分段，达到更小粒度的资源复用


同时能够通过调整每段的线程数和队列大小，优化资源配置，
毕竟有的步骤处理的慢，有的处理的快
这样达到系统整体的更优配置


通过事件驱动，把不同阶段的处理串起来


这个结构，比前面说的两种结构
性能更高，吞吐量更大，
并且每段都可以看做一个流量的缓存，
系统更稳定
所以，目前各种要求高性能高稳定的各种中间件，


一般都是基于SEDA的
讲完了。
提问环节