Storm 稳定态
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.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的发送队列里拿数据放到接受队列
