SEDA思想实现燕星20路由Emergint.ppt

SEDA思想实现燕星2.0路由——Emergint By Li Xin SEDA:新的软件体系架构 SEDA = staged event driven architecture by Matt D. Welsh, CS, UC Berkeley Staged: 将系统分为若干的阶段，每一阶段是一个模块，有明显的功能独立性 Event: 模块间进行通讯的手段，包罗万象，任何模块间需要传递的内容都可以用Event来表示 SEDA的先进性——传统架构 传统的软件架构：多线程，通常是为某一个任务（如TCP连接）单独分配一个连接 当线程数达到一定的数量的时候由于在线程之间不断切换，系统的额外开销增大，效率明显下降 作为一个responsive, robust, and always available的系统，这样远远达不到要求 SEDA的先进性——传统架构的改进 一些系统的解决方案 Apache IIS——限制连接的数目，以达到限制系统内的线程数量的目的 效果：系统高throughput，保持高效率，但是忽略了公平性 SEDA的先进性—Thread Server Throughput Degradation SEDA的先进性 我们的目标：系统的吞吐量在未达到饱和时随着并发度的增加而增大，一旦达到饱和，吞吐量将几乎维持恒定。而在达到饱和后所有用户的反应时间应是公平的随着用户的增多线性增长。 SEDA的先进性—Event-driven Server Throughput Degradation SEDA的先进性 SEDA采用非阻塞IO，将系统划分成几个stage，stage间以Event来通讯，通过对Event队列的控制来达到调整系统性能的目的 SEDA将系统依据功能分为几个不同的阶段，每个阶段由自己独立的运行参数，系统瓶颈很容易被定位 SEDA的结构 系统 = stage + stage +…+ stage Stage通过Event互相通讯 Event是装在Event Queue中的，每个stage都可以向其他的某些stage enqueue event。 Stage采取某种策略从Event Queue中取出Event进行处理 SEDA的结构——一个stage SEDA的结构——一个http sever 燕星2.0的路由——Emergint 燕星系统内每个存储的对象都有一个8个十六进制位的OID，每个节点都有一个6个十六进制位的NID。对象由与其前缀相同的节点进行存储 系统内的对象的定位与路由都通过Emergint来实现 Emergint的大致思想 某节点定位一个对象，就是要找到具有与该对象OID前六位相同的NID的节点 每转发匹配一位，每个节点都有length(NID)级邻居，节点根据消息已转发的步数寻找邻居节点再转发 燕星2.0的路由规划 燕星2.0的路由规划 MainStage是整个路由系统的灵魂，相对复杂，虽然是一个stage，内部可能会有相当多的私有方法 大部分行为逻辑要对路由表进行操作，而sandstorm的全局变量（即所有阶段都可见的变量）支持得不好，所以不必要更细致划分 本实现版本的数据结构 Node:节点类，包括该节点的NID，ip地址和端口，路由表是一个三维的Node类数组 MessageElement:可以作为事件在阶段见传递，是符合系统内部消息格式的消息。该类提供其与字节流的相互转换 OID与NID:把ID的每个十六进制位放进一个byte中，并提供比较和转换等方法 目前的成果 有一个可演示路由过程的版本 可以看到节点加入系统，退出系统和对对象进行定位的过程 为实现方便，OID设置为8位，NID为4位，但向实际系统转换很容易 由于运行环境稀少（该系统运行在Linux下，且需要安装SEDA的一个实现版本——sandstorm），因此还没有拿到大机群测试的结果 SEDA使用的感受与体会 由于采用非阻塞I/O原语，确实能提高通讯效率 采用java语言实现非常恰当，Event的回收不需要自己关心 Stage的作用相当于将系统划分为几个模块。软件的分析与设计更接近于结构化方法，数据流图一定要画。Stage内部可以使用面向对象的分析设计方法。以一种面向对象的语言实现结构化的设计，从软工的角度值得商榷 SEDA使用的感受与体会 SEDA的最大缺点在于：stage间的通讯过于错综复杂。Event类型繁多，包罗万象，使得系统非常强大，同时也造成混乱 Event类别是Stage采取动作的依据，关键代码中程序很少有直接的subroutine call，有点类似FSM 传统方法每线程负责一个连接，利用一个思维上比较连续的逻辑，从连接读写数据。但是以SEDA实现需要在stage间跳来跳去，思维不联贯 * * ObjectOperat