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分配情况如下:
spout1 | t0 t1 t2 |
---|---|
spout2 | t3 t4 |
bolt1 | t5 t6 t7 t8 |
bolt2 | t9 t10 t11 t12 |
而每个task会被顺次分配到每一个worker下面,这个topology的结构如下:
image.png2. 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.png3. 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的发送队列里拿数据放到接受队列
网友评论