本质
1.基于消息的流水线处理模型
2.是一套类似MapReduce一样的编程模型
3.内核是一套调度系统
适合的业务
1.高并发的计算任务
2.数据流之间相互无依赖
编程模型
1.Topology：即一个数据流的拓扑结构，包含多个Spout和Bolt
2.Spout：从外部获取数据，包含DB，Hbase，Kafka等
3.Bolt ：计算单元，系统内计算流转数据 
角色
1.Nimbus： 资源调度角色，可主备
2.Supervisor： 接受nimubs 任务安排，启动任务，管理Worker
3.Worker： 进程
4.Executor： 执行线程,继承自Runnable
5.Task： 执行逻辑单元,继承自Runnable
ack机制
ack闭环，保证数据不丢失（以后会结合源码分析ack实现）
1.设置acker 的并行个数，如果设置为0,acker失效，不能保证数据不丢失,或者设置配置topology.acker.executors（默认为null，即与该任务的work数一致）
stormConf.setNumAckers(JStormUtils.parseInt(conf.getProperty("jstorm.acker.num")));
2.Spout 发送消息必须带msgId，否则不能实现acker闭环
collector.emit(new Values(strMsg), new KafkaMessageId(partition, toEmitMsg.offset()));
3.Bolt发送消息必须传入接收到的tuple作为anchors参数的值，这样才能锚定tuple，将此Bolt纳入Ack闭环中
public List<Integer> emit(String streamId, Collection<Tuple> anchors,List<Object> tuple)
4.topology.max.spout.pending设置，默认为null，无限。对spout task接收速度进行流控。当topology.max.spout.pending=5000,对于spout而言，还有5000个没有进行ack，就会停止spout的nextTuple。
topology.max.spout.pending设置后，会降低整个系统的吞吐量，可根据自己系统要求自行设置，以先某个数值开始，不断增加，最终达到系统稳定且吞吐量合适
topology.max.spout.pending要起作用，必须锚定tuple，因为这个是在ack闭环的基础上实现的。所以必须满足条件1,2,3
5.spout发送的事件在超时时间(topology.message.timeout.secs 默认为30s)内没有最终ack闭环，系统就会自动调用spout.fail,由spout编写者自行处理，一般在里面实现重传，如果实现不好，或者不处理，数据也会丢失
6.acker闭环并不保证数据不丢失，只是提供了一个机制可以实现数据不丢失，取决于Spout的编写者。acker闭环完成会调用spout.ack,闭环失败或者超时会调用 spout.fail
作者：glowd
原文：https://blog.csdn.net/zengqiang1/article/details/78436585
版权声明：本文为博主原创文章，转载请附上博文链接！
