流数据处理strom
在2011年Storm开源之前,由于Hadoop的火红,整个业界都在喋喋不休地谈论大数据。Hadoop的高吞吐,海量数据处理的能力使得人们可以方便地处理海量数据。但是,Hadoop的缺点也和它的优点同样鲜明——延迟大,响应缓慢,运维复杂。
有需求也就有创造,在Hadoop基本奠定了大数据霸主地位的时候,很多的开源项目都是以弥补Hadoop的实时性为目标而被创造出来。而在这个节骨眼上Storm横空出世了。
一个计算任务成为一个Topology(拓扑逻辑),由多个spout和多种bolt组成
stream:数据流,是时间无上界的tuple元祖序列
Tuple:一次消息传递的基本单元,可以被理解为键值对
task:逻辑线程,是不会变的,又代码决定
executor:物理线程,每一个executor执行多个task,executor是动态分配的,和整个集群相关,因此一个集群不止有一个job,当所有的executor用完时,新提交的job只能等待
nimbus:总控节点
supervisor:工作节点,负责监听从nimbus分配的任务,据此启动或停止工作进程(worker)
supervisor节点包含多个worker占位槽,集群中的所有topology共用。
zookeeper集群:Zookeeper是Storm重点依赖的外部资源。Nimbus和Supervisor甚至实际运行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根据Zookeerper上的心跳和任务运行状况,进行调度和任务分配的。zooker保存所有的元数据
nimbus和zookeeper通信,zookeeper和supervisor通信,nimbus和zookeeper不直接通信
zookeeper:
- task文件夹保存task信息
- assignment文件夹保存任务代码
- workerbeats文件夹保存所有worker的心跳信息
一个supervisor对应N个worker节点
一个worker节点启动N个executor
一个executor对应N个task
消息保证机制
每个topology有一个超时设置,如果strom在超时时间内检测不到某tuple是否成功,则标记失败,重新发送
strom分布式
- task之间的并行
- 先后task之间的流水线并行
Acker 异或算法
原理:收集所有的spout和bolt接受ID和发送ID,然后异或,如果为0,说明记录正确