Storm基础理论

Storm流式计算基础
.note-content {font-family: "Helvetica Neue",Arial,"Hiragino Sans GB","STHeiti","Microsoft YaHei","WenQuanYi Micro Hei",SimSun,Song,sans-serif;}

.note-content h2 {line-height: 1.6; color: #0AA89E;}
.note-content {background: #FFFFFF;}
.note-content h1 {color: #7AB3A7;}
.note-content h3 {color: #147A67;}

Storm流式计算基础

○ 什么是Storm？

Storm是一个开源的、分布式、流式计算系统。

大家都知道现在我们都处于一个信息爆炸头的时代，有很多公司处理的数据量就很大，而且增长速度很惊人。但作为一个程序猿还是很懒的，当我们目前面临1wQPS的时候，绝对不会去考虑10wQPS的时候我们该怎么做。就在我们刚写完一个系统的时候，几倍的流量就来打你的脸，那这个时候该怎么办呢？大部分的公司在这个时候想到的办法就是升级服务器配置。因为开发前面的那个系统已经耗费不少时间了，要是开发一个几倍流量的系统，估计得雇佣多几个更有经验的程序猿，开发更长的时间才能开发出来。这个估计老板会选择买点更好的服务器算了。一开始这确实是个最方便最省钱的办法，但是很多公司都踏上了一条升级服务器配置的不归路。升着升着普通的机器就满足不了用户的需求了。

所以说当数据规模达到这种程度的情况下，资金也比较雄厚了，已经有了足够牛逼的开发团队，许多公司都不愿意当这个冤大头了，迫于无奈之下都想到的是同一个办法：把任务拆解到多台计算机上去执行，对外只提供一个接口

1.数据量大--------> 分
2.                 布
3.增长太快--------> 式

之前有人曾经开发过分布式系统，都没有成功。后来google提出了三篇重要意义的论文，BigTable、GFS、MapReduce。然后被人看到这三篇论文之后就开发出了hadoop，基于hadoop的改进hadoop的系统就陆续出现了。由于hadoop有一整套的生态系统，所以现在人们谈到分布式就必谈到hadoop。但hadoop并不能解决大部分的计算需求。MapReduce只能处理批量式计算需求，数据得在计算之前就都准备好。收集数据得花一段时间，再进行计算又花一段时间，因此没有实时性。

\	批量计算(MapReduce)	流式计算(Apache Storm)
数据到达	计算开始前数据已准备好	计算进行中数据持续更新到来
计算周期	计算完成后会结束计算	一般会作为服务持续更新运行
使用场景	时效性要求低的场景	时效性要求高的场景

○ Storm基本组件

Storm的主从结构

1.                     Supervisor
2.         Zookeeper   Supervisor
3.Nimbus ⇄ Zookeeper ⇄ Supervisor
4.         Zookeeper   Supervisor
5.                     Supervisor

主从结构：简单，高效，但主节点存在单点问题

Nimbus
- 主节点
- 只负责整体分配工作
- 不具体干活
- 老板
Supervisor
- 从节点
- 直接管理干活的Worker
- 小组经理
Worker
- 真正干活(TASK)的进程
Heron改进
Storm DRPC
Storm UI

Storm作业提交运行流程

用户编写Storm Topolgy
使用Client提交Topology给Nimbus
Nimbus指派ask给Supervisor
Supervisor为Task启动Worker
Worker执行Task