JStorm中消息确保处理机制

JStorm中消息确保处理机制

      从一个spout发射(emit)出去的元祖(tuple),到达下层bolt时候,可能有bolt拆成多个元祖。这样,元祖从spout出发,经过不同下层bolt的处理变成多个元祖,从而形成了一个以spout为根节点的树形结构。

    JStorm会创建并且跟踪从spout发射出去的每一个元祖,当跟踪到在这个树形结构中,所有的叶子节点全被标记处理完毕的时候,才会认为树根节点即从sput发射出去的该元祖成功处理。
    为了让JStrom创建和跟踪元祖树,我们要做以下两件事情:

 - 从bolt里发射新元祖时候,确保anchor to input tuples。
 outputCollector.emit(tuple, new Values(order)).
 tuple要传的参数。

 - bolt处理完元祖要通知JStorm。
  outputCollector.ack(tuple);
   outputCollector.fail(tuple);



确保消息机制的线程问题:(JStorm wiki)

    当topology.max.spout.pending 设置不为1时(包括topology.max.spout.pending设置为null),spout内部将额外启动一个线程单独执行ack或fail操作, 从而nextTuple在单独一个线程中执行,因此允许在nextTuple中执行block动作,而原生的storm,nextTuple/ack/fail 都在一个线程中执行,当数据量不大时,nextTuple立即返回,而ack、fail同样也容易没有数据,进而导致CPU 大量空转,白白浪费CPU, 而在JStorm中, nextTuple可以以block方式获取数据,比如从disruptor中或BlockingQueue中获取数据,当没有数据时,直接block住,节省了大量CPU。

   但因此带来一个问题, 处理ack/fail 和nextTuple时,必须小心线程安全性。

   附属: 当topology.max.spout.pending为1时, 恢复为spout一个线程,即nextTuple/ack/fail 运行在一个线程中。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Dreamer who

你的鼓励将是我创作的最大动力!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值