流数据处理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，说明记录正确
