为了账号安全,请及时绑定邮箱和手机立即绑定

Storm 稳定态

2018.10.15 11:31 729浏览

1.Task的分配

假设一个topology有4个worker,2个spout,2个bolt。spout1有4个task,spout2有2个task,bolt1有4个task,bolt2有4个task。(默认一个task对应一个Executor)

storm会为每个task顺次分配taskid,task分配情况如下:

spout1t0 t1 t2
spout2t3 t4
bolt1t5 t6 t7 t8
bolt2t9 t10 t11 t12

而每个task会被顺次分配到每一个worker下面,这个topology的结构如下:

image.png

2. Spout读取Kafka的逻辑

Kafka是有分区的,spout读取kafaka的partition的过程和task分配的过程类似,也是顺次分配。

继续上面的例子,假如spout1读取的kafka的topic1有3个partition,则每个task读取一个partition,他们之间并行处理,互不干扰。

image.png

由于kafka的数量是动态增加的,加入这时候又多了一个partition,则partition数大于spout的task数,这时候顺次排列,应该有task-0读取partition-4

image.png

如果此时partition-3被下掉了,则task-2会空余出来

注意由于task并行的互不干扰的处理自己对应的task,当task数大于partition数的时候,多出来的task并不会去和其他task共同处理一个partition,而是会保持空闲状态

image.png

3. Storm的at least once语义 {#id-3.Storm的atleastonce语义}

Storm的语义是at least once(至少处理一次)语义做的是最好的。at most once和tradient的state等其他语义用的并不多,这里不做讨论。

Spout在读取kafka的数据的时候,会将offset(偏移量)记录到zookeeper里面,但是由于spout读取kafka的数据并不是有序的,所以偏移量不能保证记录到所有已经正常处理的数据,

所以他的offset只会记录到拥有最小间隔的最大连续处理量的位置

image.png

如上图,加入在这个时候tuple1-20,24-30,35-40都已经处理了,但是由于20-24,30-35之间间断了,而最大的连续处理了是tuple1-20,所以如果此时worker或者spout的executor挂了,

这时的offset只能寄到tuple20的位置,当重启的时候,只能从tuple20的位置继续往下处理,这时tuple24-30,35-40会又被处理一次(被处理了两次),所以Storm的支持的语义是at least once(至少处理一次)。

正因为如此,我们需要在业务逻辑处理中考虑到这一点--我们的数据可能会被重复多次发送

4.Spout和Bolt之间的数据流

spout的task将数据发给哪个bolt,和bolt的task之间的数据发送,是由grouping决定的。但是数据的传输是以worker为单位的。

对于Spout发送的每一个tuple,都会记录他的发送者是谁,接受者是谁,但是真实的数据传输是由worker来完成的。

每一个Spout和Bolt都会有一个发送队列和接收队列,spout处理完数据放入自己的发送队列,bolt不断的从spout的发送队列里拿数据放到接受队列

小结

Storm稳定态里的数据流动主要包括以下几类:

  1. spout读取kafka

    1. 如果某个spout的task之前没有读取过当前分配的partition,或者刚启动的时候,会从zookeeper里读取offset

    2. spout正常读取某个partition,会在内存里记录哪个tuple被ack了,哪个被fail了,哪个还未超时。然后从最小间隔的连续的偏移量读取,过滤掉被ack的和未超时的

    1. spout向zookeeper中读写偏移量

    2. spout读取kafka的数据。会受kafka分区数和spout并发数的影响,这些配置修改后,会出发rebalance,将任务分配情况重新写入zookeeper,然后worker重新拉取配置。重新分配之后:

  2. spout发送数据到bolt,bolt与bolt之间的数据流动

    1. spout发送数据给其他worker,会记录当前的taskid,接受者的taskid,发送给哪个worker。然后把发送消息写入发送队列里,又worker进行发送

    2. worker从接受队列里读取数据给bolt

  3. 心跳汇报

    1. worker要定期的写心跳到zoopkeer,汇报对象是worker粒度的,而不是bolt,spout这些组件,所以如果某个bolt被阻塞了或者假死了,nimbus并不会知道。

    2. superviors定期写心跳到zookeeper

    3. nimbus统一读取汇总心跳信息(统一由nimbus读取,保证分布式一致性)

  4. zookeeper集群之间的数据流动(非此次总结重点)

  5. nimbus和superviors之间的数据流动,如nimbus像superviors分配worker和task,superviors拉取jar包,依赖等(非此次总结重点)

抛一个点:上游往下游发送数据会不会有阻力拖住发送的速度,都有什么方式:

  1. Config.setMaxSpoutPending() 设置一个spout最多只能发送n条数据出去(最多只能有1000条数据在外面),超过了这个数量就不发了

  2. back press:https://blog.csdn.net/qq_21125183/article/details/80708142

  3. worker之间的NIO 如果下游未处理数据量太多,会导致下游不在读取数据,此时上游写不进来。

             




作者:Meet相识_bfa5
链接:https://www.jianshu.com/p/7aaf58e41695


点击查看更多内容
0人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消