storm spout的速度抑制问题

标签：修改   指标   mon   span   else   源码分析   function   color   rate   

转发请注明原文地址：http://www.cnblogs.com/dongxiao-yang/p/6031398.html

    最近协助同事优化一个并发消费kafka数据用来计算的任务，压测过程中发现有两个spout对应的topic消费速度明显低于其他topic的指标，每个spout分配10个并发消费速度到了1w左右完全就上不去了，通过监控埋点分析出spout以及下游的bolt代码块里面的业务代码执行耗时完全不高于其余可以正常消费的topic对应的spout组件。

    最后只能摘出有问题的代码新做一个demo进行测试，发现把nextTuple中 collector.emit()这个方法的调用注销，只保留读取kafka的逻辑后demo程序的消费kafka速度也同样卡在了一个很低的速度，查看问题程序代码nextTuple的调用逻辑大概如下

if(booleanfunction)

{

collector.emit(....)

}

其中booleanfunction指代一个执行了业务代码并返回boolean值的方法，推测这个方法在实际线上并没有每次都返回true进入调用emit方法的环节，

修改代码如下

if(booleanfunction)

{

collector.emit(....)

}

else

{

collector.emit(....)

}

相当于每次nextTuple调用都会运行emit方法，任务重新上线后10个spout消费轻松突破30W+。

     产生问题的原因是由于storm的spout在nextTuple代码执行的时候，emit方法每次执行后会在内存里更新一个emitted-count的变量值，如果spout的发现emitted-count跟上次调用完毕后的值一致，表明nextTuple函数没有发送出去消息，此时会调用spout-wait-strategy的的emitEmpty方法，默认这个方法会sleep一毫秒。所以在没有emit的情况下nextTuple理论上最大的调用频率就是1000/s

。

参考资料

1 storm spout emit 问题

2 《Storm 源码分析》 第10章 10.3.5 消息循环

storm spout的速度抑制问题

标签：修改   指标   mon   span   else   源码分析   function   color   rate   

原文地址：http://www.cnblogs.com/dongxiao-yang/p/6031398.html