参考博客:https://www.cnblogs.com/Transkai/p/10909117.html加上个人理解
消息不丢失机制ack
ack是什么
ack 机制是storm整个技术体系中非常闪亮的一个创新点。
通过Ack机制,spout发送出去的每一条消息,都可以确定是被成功处理或失败处理, 从而可以让开发者采取动作。
比如在Meta中,成功被处理,即可更新偏移量,当失败时,重复发送数据。
因此,通过Ack机制,很容易做到保证所有数据均被处理,一条都不漏。
另外需要注意的,当spout触发fail动作时,不会自动重发失败的tuple,需要spout自己重新获取数据,手动重新再发送一次
ack机制即, spout发送的每一条消息,
l 在规定的时间内,spout收到Acker的ack响应,即认为该tuple 被后续bolt成功处理
l 在规定的时间内,没有收到Acker的ack响应tuple,就触发fail动作,即认为该tuple处理失败,
l 或者收到Acker发送的fail响应tuple,也认为失败,触发fail动作
另外Ack机制还常用于限流作用: 为了避免spout发送数据太快,而bolt处理太慢,常常设置pending数,当spout有等于或超过pending数的tuple没有收到ack或fail响应时,跳过执行nextTuple, 从而限制spout发送数据。
通过conf.put(Config.TOPOLOGY_MAX_SPOUT_PENDING, pending);设置spout pend数。
这个timeout时间可以通过Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS来设定。Timeout的默认时长为30秒
如何使用Ack机制
spout 在发送数据的时候带上msgid
设置acker数至少大于0;Config.setNumAckers(conf, ackerParal);
在bolt中完成处理tuple时,执行OutputCollector.ack(tuple), 当失败处理时,执行OutputCollector.fail(tuple);
推荐使用IBasicBolt, 因为IBasicBolt 自动封装了OutputCollector.ack(tuple), 处理失败时,抛出FailedException,则自动执行OutputCollector.fail(tuple)
如何关闭Ack机制
有2种途径:
spout发送数据是不带上msgid
设置acker数等于0
基本实现
Storm 系统中有一组叫做"acker"的特殊的任务,它们负责跟踪DAG(有向无环图)中的每个消息。
acker任务保存了spout id到一对值的映射。第一个值就是spout的任务id,通过这个id,acker就知道消息处理完成时该通知哪个spout任务。第二个值是一个64bit的数字,我们称之为"ack val", 它是树中所有消息的随机id的异或计算结果。
spout id到一对值的映射:<TaskId,<RootId,ackValue>>
它的意义为:TaskId,<Spout的任务id(即系统生成的随机id),ackValue>
Task-0,64bit,0
ack val表示了整棵树的的状态,无论这棵树多大,只需要这个固定大小的数字就可以跟踪整棵树。当消息被创建和被应答的时候都会有相同的消息id发送过来做异或。 每当acker发现一棵树的ack val值为0的时候,它就知道这棵树已经被完全处理了。
通过以下图示进行理解:
这张图的bolt1和bolt2表示第一个bolt类的两个并行度,0001是Taskid,0010和1011是消息的随机id,xor是异或运算,
0010 xor 1011 = 1001,所以如果当spout里的消息成功发送则此时的acker里面保存的spout id到一对值的映射应该是0001:1001,(具体的应该是这样:<0001,<Spout的任务id(即系统生成的随机id),1001>>???不知道此处是否理解错误)
观察这张图,发现:spout里面的两个消息分别发送到第一个bolt类的两个并行度里(0010->bolt1,1011->bolt2),并且bolt1里面产生了新的消息(消息的随机id为0110)
如果bolt1里面的消息成功处理,那么有:0010 xor 0110 = 0100,acker里面应该有:1001 xor 0100 = 1101(1001是上一步acker里面保存的ack val)则此时保存如下内容:0001:1101(具体的应该是这样:<0001,<Spout的任务id(即系统生成的随机id),1101>>???不知道此处是否理解错误)
bolt2里面产生了新的消息(消息的随机id为0111)
同理,如果bolt2里面的消息成功处理,那么有:1011 xor 0111 = 1100,acker里面应该有:1101 xor 1100 = 0001(1101是上一步acker里面保存的ack val)则此时保存如下内容:0001:0001(具体的应该是这样:<0001,<Spout的任务id(即系统生成的随机id),0001>>???不知道此处是否理解错误)
bolt1和bolt2里面产生的新消息(消息随机id分别为0110和0111),产生的新消息继续向下发送处理,当bolt3里的消息处理成功,则有:0110 xor 0111 = 0001,最后acker里面有0001 xor 0001 = 0000具体的应该是这样:<0001,<Spout的任务id(即系统生成的随机id),0000>>???不知道此处是否理解错误)
此时acker里的ack val值为0了,那么它就知道这棵消息树已经被完全处理了。因为消息的随机ID是一个64bit的值,因此ack val在树处理完之前被置为0的概率非常小。假设你每秒发送一万个消息,从概率上说,至少需要50,000,000年才能会有机会发生一次错误。即使如此,也只有在这个消息确实处理失败的情况下才会有数据的丢失!
spout与bolt的其他开发方式
对于spout,有ISpout,IRichSpout,BaseRichSpout
对于bolt,有IBolt,IRichBolt,BaseRichBolt,IBasicBolt,BaseBasicBolt,IBasicBolt。BaseBasicBolt不用每次execute完成都写ack/fail,因为已经帮你实现好了。
坑在哪里?
1、BaseBasicBolt
ack方法有回调
2、BaseRichBolt
ack方法没有回调