原创文章,转载请注明出处:http://blog.csdn.net/jmppok/article/details/17248131
Storm可以在Topology运行过程中调整其并发度。其原理如下:
4. rebalancing
(1) startup:将状态转换成do-rebalance
(2) kill: 实际上执行的是 kill-transition 方法,将 topology 的状态先改为 killed, 然后经过 kill-time 的时间,将topology remove
(3) do-rebalance: 实际上是重新将任务分配,与初始分配任务不同,它假设所有的任务都是活跃的,所有的端口都不要判断是否需要保留,也就是说所有的任务重新分配,无论某些端口上的任务分配已经满足均衡要求。
具体可参考:Storm中Topology的状态
从上面可以看到,rebalance过程中会杀掉topology然后对其进行重新分派。
这样问题就来了,如何保证Topology的可靠性。
即如果用户正在使用该Topology,怎么保证rebalance过程中用户的请求和数据不会丢失?
google之,发现有人遇到了同样的问题:
原文地址:http://osdir.com/ml/java-clojure-storm/2012-03/msg00385.html
其实Storm本身已经提供了该问题可靠性保证。大致的原理是:
spout发出的所有数据,都有一个acker对其进行追踪,无论处理成功、失败或者超时,都会告知spout。如果spout发现消息处理失败或丢失,则会重新发送该消息。
结合Topology rebalance的过程,首先de-active,这时候topology的状态被保存。未被处理的消息由acker追踪。
当topology重新分配后,spout发现已发出的消息未被处理,则重新发射这些消息。
具体可参照:strom 如何保证可靠性
通过一个DRPC Topology进行测试,测试步骤如下:
1)创建一个DRPCTopology,并将其提交到Storm集群中运行;
topology的功能是原封不动的返回请求的String。
2)通过DRPCClient对其进行不间断访问;
DRPCClient通过一个循环0-1000000,发送"1","2","3"...到topology中,获取返回结果后输出(同样是"1","2","3"...)
3)在DRPCClient运行过程中,使用rebalance命令,调整Topology的workerNum和Spout、Bolt的并行数。
4)观察DRPCClient的运行情况,发现reblance过程中,当topology被kill掉时,DRPCClient的请求会出现阻塞,但当topology rebalance
完成后即恢复正常,且输出结果"1","2","3"...连续,无丢失。从而证明Storm具有很好的可靠性。
5)通过观察,大体发现rebalance的时间为10秒左右,这个仅供参考。