背景
限流控制,又称 反压 (backpressure), 这个概念现在在大数据中非常火爆, 尤其是最近Heron/Spark都实现了这个功能。其实在jstorm 0.9.0 时,底层netty的同步模式,即可做到限流控制, 即当接收端能处理多少tuple, 发送端才能发送多少tuple, 但随着大面积使用, 发现netty的同步模式会存在死锁问题, 故这种方式并没有被大量使用。
原理
后来自2015年6月,twitter发布了heron的一篇论文, 描叙了,当下游处理速度跟不上上游发送速度时, 他们采取了一种暴力手段,立即停止spout的发送。 这种方式, jstorm拿过来进行压测, 发现存在大量问题, 当下游出现阻塞时, 上游停止发送, 下游消除阻塞后,上游又开闸放水,过了一会儿,下游又阻塞,上游又限流, 如此反复, 整个数据流一直处在一个颠簸状态。
真正合适的状态时, 上游降速到一个特定的值后, 下游的处理速度刚刚跟上上游的速度
什么样才能触发反压
jstorm的限流机制, 当下游bolt发生阻塞时, 并且阻塞task的比例超过某个比例时(现在默认设置为0.1), 即假设一个component有100个并发,当这个component 超过10个task 发生阻塞时,才会触发启动反压限流
什么样的情况才能判断是阻塞
在jstorm 连续4次采样周期中采样,队列情况,当队列超过80%(可以设置)时,即可认为该task处在阻塞状态
触发谁限流
根据阻塞component,进行DAG 向上推算,直到推算到他的源头spout, 并将topology的一个状态位,设置为 “限流状态”
怎么限流
当task出现阻塞时,他会将自己的执行线程的执行时间, 传给topology master, 当触发阻塞后, topology master会把这个执行时间传给s