Storm的acker确认机制】的更多相关文章

Storm的acker消息确认机制... ack/fail消息确认机制(确保一个tuple被完全处理) 在spout中发射tuple的时候需要同时发送messageid,这样才相当于开启了消息确认机制 如果你的topology里面的tuple比较多的话, 那么把acker的数量设置多一点,效率会高一点. 通过config.setNumAckers(num)来设置一个topology里面的acker的数量,默认值是1. 注意: acker用了特殊的算法,使得对于追踪每个spout tuple的状态…
概念,见博客 Storm概念学习系列之storm的可靠性  什么业务场景需要storm可靠性的ACK确认机制? 答:想要保住数据不丢,或者保住数据总是被处理.即若没被处理的,得让我们知道. public void nextTuple() { num++; System.out.println("spout:"+num); int messageid = num; //开启消息确认机制,就是在发送数据的时候发送一个messageid,一般情况下,messageid可以理解为mysql数据…
转载请注明原创地址http://www.cnblogs.com/dongxiao-yang/p/6142356.html Storm 的拓扑有一些特殊的称为"acker"的任务,这些任务负责跟踪每个 Spout 发出的 tuple 的 DAG.开启storm tracker机制的前提有三个: 1. 在spout emit tuple的时候,要加上第3个参数messageid 2. 在配置中acker数目至少为1 3. 在bolt emit的时候,要加上第二个参数anchor tuple…
worker进程死掉 在一个节点 kill work进程 比方 kill 2509  对work没有影响 由于会在其它节点又一次启动进程运行topology任务 supervisor进程死掉 supervisor进程kill掉 对work进程没有影响  由于他们是互相独立的! . nimbus进程死掉(存在HA的问题) nimbus假设死掉 整个任务挂掉 存在单点故障问题!(hadoop2有ha!.!!.! storm没有ha高可用) 节点宕机(和supervisor是一样的) ack/fail…
在很多应用场景中,分布式系统的可靠性保障尤其重要.比如电商平台中,客户的购买请求需要可靠处理,不能因为节点故障等原因丢失请求:比如告警系统中,产生的核心告警必须及时完整的知会监控人员,不能因为网络故障而丢失数据. Storm消息可靠性保障是Storm核心特性之一,其中消息树的跟踪管理机制是Storm核心算法之一,本文将详细介绍Storm消息可靠处理机制.我们从Storm初探中的例子入手. 一.消息处理流程 1. Spout节点 (1) Spout接收到一个文本消息: msg1 刘备 关羽 张飞…
作者:Jack47 转载请保留作者和原文出处 欢迎关注我的微信公众账号程序员杰克,两边的文章会同步,也可以添加我的RSS订阅源. 一个Storm拓扑,就是一个复杂的多阶段的流式计算.Storm中的组件(Component)就是对各个阶段的一个抽象,其中的Spout是生产者的角色,它负责源源不断地从Storm外部接收消息,扔给下游的组件处理,下游组件处理完成后,最终输出到外部的存储系统. 本文主要讲解消息在Storm内部的各个组件(Component)之间如何进行传递,本文适用于JStorm 2.…
消息确认机制 在之前异常处理部分就已经写了,对于consumer的异常退出导致消息丢失,可以时候consumer的消息确认机制.重复的就不说了,这里说一些不一样的. consumer的消息确认机制 当一个消费者收到一个快递,但是这个包裹是破损的,这时候一般会有以下选择 拒收快递,让快递员把快递寄回. (如果有多个consumer可能这条消息会到其它的consumer中,如果只有一个,那么下次获取还是可以拿到) 签收快递,然后偷偷的扔了(钱多任性) 拒收快递,联系商家再给我补发一个 下面是具体的方…
JMS中为数不多的重点就是消息的确认机制,下面分别介绍J2EE和Spring的MessageListenerContainer的确认机制 J2EE中JMS确认机制 在JMS规范中一共4种确认方式 AUTO_ACKNOWLEDGE当调用recieve方法成功后或MessageListener处理函数成功返回后进行确认 CLIENT_ACKNOWLEDGE客户端通过message的acknowledge方法手动确认 DUPS_OK_ACKNOWLEDGE延迟确认,在对重复接受同一消息不敏感时可以选用…
概述 对Acknowledge机制进行测试. 此处的测试是针对Consumer的确认设计的:对于Producer的确认是透明的,无法提供测试. 测试实例 设计demo,测试三种确认机制. 测试机制 测试实例 结果预测 AUTO_ACKNOWLEDGE 接收正常 消息出队量=消息入队量 接收异常 消息出队量=0 CLIENT_ACKNOWLEDGE 1次确认/2条消息 - 每2条消息确认1次 每次确认2条信息 从不确认 消息出队量=0 DUPS_OK_ACKNOWLEDGE 每一次接收消息后,使线…
在前面的文章中提到了queue和consumer之间的消息确认机制:通过设置ack.那么Publisher能不到知道他post的Message有没有到达queue,甚至更近一步,是否被某个Consumer处理呢?毕竟对于一些非常重要的数据,可能Publisher需要确认某个消息已经被正确处理. 在我们的系统中,我们没有是实现这种确认,也就是说,不管Message是否被Consume了,Publisher不会去care.他只是将自己的状态publish给上层,由上层的逻辑去处理.如果Message…