本质
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
版权声明:本文为博主原创文章,转载请附上博文链接!