Spamfilter

节点：anaspout，traspout，tokenizerbolt，wordprobabilitybolt，bayesbolt，kafkasink
节点并行度设置：

• 112211
  

  storm多节点运算正确SF_112211.jpg

• 112231
  

  storm多节点运算正确SF_112231.jpg

• 112232
  

  storm多节点运算正确SF_112232.jpg

WordCount 故障记录

并行度：1111
数据源：“storm”+（i++）+“生成时间”，生成间隔设定：1s
故障前：

故障前
故障恢复后
故障恢复后2
故障恢复后3
故障恢复：丢失数据

61的延迟处理：29s
62:28s
48-61中间的数据生成了，且被丢弃了。

根据官网的API设置bolt的anchor和spout 的msgid，acker的数目设置成1，还是存在了丢失数据

正确设置？ kill spilit
还是丢失

并行度：1111
数据源：“storm 生成时间”，间隔1s

故障时：

故障时红色点

故障恢复后：

恢复后

可以看出丢失了407689~420701的数据

kill没有state的spout
spout里有i++
那么恢复后：i重新变成0，相当于spout重新new了个新的，累计的变量初始化了

累计的变量i初始化了

**注意**：kill拓扑重新提交后，也能获取state后重新恢复到kill前的状态

Top-k

没故障运行：左
错误发生48：右

对比1
结论：出错前结果都一样 对比2

发现错误恢复后，结果不对。
而且48~100多的数据实在恢复后快速输出，不是正常产生，
经过前面的wordcount发现，
故障会导致中间部分数据的丢失，
可以查看map的size看看前面的有无丢失？

kill countbolt 发现，word_count map里面的数据会有残余影响下面的排名。

window10+TOP10全拉取对比

分析：word_count残留了上次的数据，比如enterprises不应该在下面出现的，但是每次都有，说明没执行enterprises滑出窗口次数-1的操作。

观察2

右边的直接跳到了正常执行的195的数据，丢失了166~195的数据

Replay Test：在spout中编写了ACK机制

并行度：111
spout----spilit----kafkasink

kill split:

35--45出错

查看日记发现收到超时提示后，重发数据：

image.png

并行度：1111
spout----spilit-----count----kafkasink

kill split:

72-86出错

重发，有些数据重复计算：分析可能是count存了出错时的部分数据状态，但是还没发送ack，spout把这部分数据也超时重发了

重发

count kill：

丢失31-46的数据

数据重发：

image.png

并行度：121
spout----spilit----kafkasink
kill 一个split

发送给kill的数据丢失 超时重发

并行度：1121
spout----spilit-----count----kafkasink

kill在78：
查看log，另一个count 58里发现会发出一部分的ack_fail流，是不是因为78的的count状态锁住了？，58里面不能更改导致了错误？

会发出ack_fail流

字：storm：75 数目：1 输出时间：1536586021596
字：storm：76 数目：1 输出时间：1536586022599
字：storm：77 数目：1 输出时间：1536586023606
字：storm：78 数目：1 输出时间：1536586024605
字：storm：81 数目：1 输出时间：1536586027615
字：storm：83 数目：1 输出时间：1536586029621
字：storm：85 数目：1 输出时间：1536586031628
字：storm：87 数目：1 输出时间：1536586033633
字：storm：89 数目：1 输出时间：1536586035638
字：storm：90 数目：1 输出时间：1536586036643
字：storm：92 数目：1 输出时间：1536586038652
字：storm：94 数目：1 输出时间：1536586040656
字：storm：96 数目：1 输出时间：1536586042660
字：storm：98 数目：1 输出时间：1536586044667
字：storm：100 数目：1 输出时间：1536586046673
字：storm：102 数目：1 输出时间：1536586048678
字：storm：104 数目：1 输出时间：1536586050683
字：storm：106 数目：1 输出时间：1536586052689
字：storm：108 数目：1 输出时间：1536586054693
字：storm：111 数目：1 输出时间：1536586057701
字：storm：113 数目：1 输出时间：1536586059705
字：storm：115 数目：1 输出时间：1536586061711
字：storm：117 数目：1 输出时间：1536586063716
字：storm：91 数目：1 输出时间：1536586063843
字：storm：93 数目：1 输出时间：1536586063845
字：storm：95 数目：1 输出时间：1536586063848
字：storm：97 数目：1 输出时间：1536586063852
字：storm：99 数目：1 输出时间：1536586063854
字：storm：101 数目：1 输出时间：1536586063856
字：storm：103 数目：1 输出时间：1536586063858
字：storm：105 数目：1 输出时间：1536586063859
字：storm：107 数目：1 输出时间：1536586063860
字：storm：109 数目：1 输出时间：1536586063862
字：storm：110 数目：1 输出时间：1536586063864
字：storm：112 数目：1 输出时间：1536586063866
字：storm：114 数目：1 输出时间：1536586063869
字：storm：116 数目：1 输出时间：1536586063874
字：storm：118 数目：1 输出时间：1536586064721
字：storm：78 数目：1 输出时间：1536586064723
字：storm：81 数目：1 输出时间：1536586064725
字：storm：83 数目：1 输出时间：1536586064729
字：storm：85 数目：1 输出时间：1536586064730
字：storm：87 数目：1 输出时间：1536586064732
字：storm：89 数目：1 输出时间：1536586064735
字：storm：90 数目：1 输出时间：1536586064736
字：storm：92 数目：1 输出时间：1536586064751
字：storm：94 数目：1 输出时间：1536586064752
字：storm：96 数目：1 输出时间：1536586064753
字：storm：98 数目：1 输出时间：1536586064754
字：storm：100 数目：1 输出时间：1536586064755
字：storm：102 数目：1 输出时间：1536586064756
字：storm：104 数目：1 输出时间：1536586064757
字：storm：106 数目：1 输出时间：1536586064758
字：storm：108 数目：1 输出时间：1536586064762
字：storm：111 数目：1 输出时间：1536586064767
字：storm：113 数目：1 输出时间：1536586064768
字：storm：115 数目：1 输出时间：1536586064770
字：storm：117 数目：1 输出时间：1536586064772
字：storm：119 数目：1 输出时间：1536586065788
字：storm：120 数目：1 输出时间：1536586066810
字：storm：84 数目：1 输出时间：1536586066816
字：storm：88 数目：1 输出时间：1536586066818
字：storm：79 数目：1 输出时间：1536586066820
字：storm：82 数目：1 输出时间：1536586066822
字：storm：86 数目：1 输出时间：1536586066824
字：storm：80 数目：1 输出时间：1536586066827
字：storm：121 数目：1 输出时间：1536586067830
字：storm：122 数目：1 输出时间：1536586068837
字：storm：123 数目：1 输出时间：1536586069840

全部fail

并行度：111
kafkaspout----spilit----kafkasink
kill 一个split

kill在40

kafkaspout能正确有序恢复!!!!!!，采用这个好

并行度：1111
spout----spilit-----count----kafkasink

kill 一个split

split延迟1s的时候，后面count不能正常运行。比如输出很迟，redis里面state都没建立

redis里state没保存，数目0

image.png

kill 1个split

结果

分析：20-39的spout未ACK导致了重发，但是数目为什么不是2？

count并行度4：乱序问题

结果输出

很多并行度：
kill拓扑，重新启动，
会读取redis中存储的状态

image.png

redis中的状态
：1000条记录，每个bolt存200个

image.png

window

topK count并行度2：那么会出现2个窗口？
输入aaaabbbccd，count5

image.png

topk

并行度count1，rank2
结果分析：kill count在榜单11，造成了12的计算错误，13的数据丢失

image.png

并行度count1，rank2：70 rank，
74 rankcheckpoint

log 74

结果分析：kill 1个70 rank在榜单15，会导致暂停
分析：除了丢失了榜单15-19，其他运算正确，和没出错的一样

image.png

结果分析：kill 1个74 rank checkpoint在榜单28，
发现没有停止进行输出，没有影响运算

image.png

但是会导致70bolt的相关信息输出fail信息：

70bolt_fail

SG

基础逻辑检验：使用testtopology，时间窗口3s，滑动1s

image.png
image.png

多并行度运算对比

wordcount：

注意sink得1，多个并行度会导致结果乱序

左边1，右边3

image.png

topk

并行度1：

image.png

1---3---1
count并行度为3：

image.png

错误运算

设置count并行度为1，运算正确：

image.png

发现多个window_bolt会维护自己的窗口，导致逻辑错误
并行度count3，rank1

image.png

总结：count和rank也不能多并行度，逻辑错误

parser多的也不行，因为顺序不一样：

image.png

parser3:，count1，filed，正常：

image.png

wordcount 多并行度

spout---split------count------sink

1333：

结论：运行错误

image.png

1331：
结果乱序

image.png