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了个新的,累计的变量初始化了
**注意**:
kill拓扑重新提交后,也能获取state后重新恢复到kill前的状态
Top-k
没故障运行:左
错误发生48:右
结论:出错前结果都一样 对比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里面不能更改导致了错误?
字: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
并行度:111
kafkaspout----spilit----kafkasink
kill 一个split
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_failSG
基础逻辑检验:使用testtopology,时间窗口3s,滑动1s
image.png
image.png
多并行度运算对比
wordcount:
注意sink得1,多个并行度会导致结果乱序
左边1,右边3
image.png
topk
并行度1:
image.png1---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.png1331:
结果乱序
image.png
网友评论