Storm的系统架构

系统架构

nimbus
调度topology，将调度信息写入ZK
管理集群，检查supervisor/worker心跳，处理异常
处理topology submit、kill、rebalance等请求
提供查询cluster/topology状态的thrift接口
提供文件（如topology程序jar包）上传下载服务
supervisor
管理worker
根据ZK调度信息启动worker
下载topology的jar包并解压
启动worker JVM进程
检查worker本地心跳，处理worker异常
定期(默认5S)在ZK更新supervisor心跳信息
worker
一个JVM进程
启动executor
负责数据传输
建立worker之间的网络连接
一对收发线程做实际的tuple收发
定期在本地文件系统和ZK更新心跳信息
WorkerHeartbeat[time-secs storm-id executors port]
executor
实际干活的线程
创建spout/bolt对象
运行两个关键线程
执行线程执行nextTuple()/execute()回调函数
传输线程将新产生的tuple放到worker传输队列
两个关键内存DisruptorQueue
Receive-queue：执行线程从这里取收到的tuple
transfer-queue：执行线程emit的tuple放到这里
zk
可靠状态存储：调度信息、心跳
存储心跳、调度信息、错误信息等元数据
当做高可用KV使用
zk路径 数据

系统架构特点

无状态
nimbus/supervisor/worker状态存在ZK中，worker里边少量本地状态在文件中，jar也存储在本地文件系统
因为无状态，所以任何进程异常后可快速恢复，比较稳定
单中心
使得topology全局调度简单
也带来可用性单点问题，仅在需要重新调度时才有问题
jar先提交到nimbus，supervisor从nimbus下载，worker多，jar大，nimbus会成为瓶颈，可把文件分发改成p2p
隔离性好
真正干活的是worker和executor，所有数据传输在worker之间完成
nimbus/supervisor全部挂掉worker也能正常运行
nimbus挂掉后，集群可正常运行(除了新topology提交)

数据传输

1、executor执行spout.nextTuple()/bolt.execute().emit tuple放入executor transfer queue
2、executor transfer thread 把自己transfer queue里面的tuple放到worker transfer queue
3、worker transfer thread 把transfer queue 里面的tuple序列化发送到远程的worker
4、worker receive thread 分别从网络收数据，反序列化成tuple放到对应executor的receive queue
5、executor receive thread 从自己的receivequeue取出tuple，调用bolt.executor
注：如果多个executor在同一个worker，本地会有优化

并发模型

注意图片中的说明文字
cluster
supervisor-node 机器级别，Node或host
worker-process
executor-thread
task-object
并发模型举例：

参考资料

storm官网Tutorial
http://storm.apache.org/documentation/Tutorial.html
storm并发模型：
http://storm.apache.org/documentation/Understanding-the-parallelism-of-a-Storm-topology.html
http://storm.apache.org/documentation/Guaranteeing-message-processing.html