Storm rebalance原理及可靠性保证

原创文章，转载请注明出处：http://blog.csdn.net/jmppok/article/details/17248131

1.rebalance原理

Storm可以在Topology运行过程中调整其并发度。其原理如下：

4. rebalancing

(1) startup:将状态转换成do-rebalance

(2) kill:  实际上执行的是 kill-transition 方法，将 topology 的状态先改为 killed, 然后经过 kill-time 的时间，将topology remove

(3) do-rebalance:  实际上是重新将任务分配，与初始分配任务不同，它假设所有的任务都是活跃的，所有的端口都不要判断是否需要保留，也就是说所有的任务重新分配，无论某些端口上的任务分配已经满足均衡要求。

具体可参考：Storm中Topology的状态

2.问题

从上面可以看到，rebalance过程中会杀掉topology然后对其进行重新分派。

这样问题就来了，如何保证Topology的可靠性。

即如果用户正在使用该Topology，怎么保证rebalance过程中用户的请求和数据不会丢失？

google之，发现有人遇到了同样的问题：

原文地址：http://osdir.com/ml/java-clojure-storm/2012-03/msg00385.html

3.Storm的可靠性保证

其实Storm本身已经提供了该问题可靠性保证。大致的原理是：

spout发出的所有数据，都有一个acker对其进行追踪，无论处理成功、失败或者超时，都会告知spout。如果spout发现消息处理失败或丢失，则会重新发送该消息。

结合Topology rebalance的过程，首先de-active，这时候topology的状态被保存。未被处理的消息由acker追踪。

当topology重新分配后，spout发现已发出的消息未被处理，则重新发射这些消息。

具体可参照：strom 如何保证可靠性 

4.测试

通过一个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秒左右，这个仅供参考。