storm中只能进行任务计算,不能保存中间结果,最后结果. 这就有一个需求,保存计算结果,最好还是分布式的,因为storm也是分布式,大数据计算. 流行的分布式计算中使用队列保存数据居多. kafka适合大量写入,但是稳定性差,项目采用的是rabbitmq. rabiitmq有2种模式: 1.集群模式(高稳定性). 2.主从模式(读速度快). 最少的是3台机器,3个实例. rabbit有长连接,短连接模式.在60秒时,要进行重连接.

热门的消息队列中间件RabbitMQ,分布式任务处理平台Celery,大数据分布式处理的三大重量级武器:Hadoop.Spark.Storm,以及新一代的数据采集和分析引擎Elasticsearch. RabbitMQ RabbitMQ是一个支持Advanced Message Queuing Protocol(AMQP)的开源消息队列实现,由Erlang编写,因以高性能.高可用以及可伸缩性出名.它支持多种客户端,如:Java.Python.PHP..NET.Ruby.JavaScript等.它

rabbitmq:实时消息传递 kafka:消息的持久化 storm:使用拓扑逻辑进行

1.定义拓扑topology public class MessageTopology { public static void main(String[] args) throws Exception { //组装topology TopologyBuilder topologyBuilder = new TopologyBuilder(); topologyBuilder.setSpout("RabbitmqSpout", new RabbitmqSpout()); topolog

一.简介:       storm中有一个很重要的特性: 保证发出的每个tuple都会被完整处理.一个tuple被完全处理的意思是: 这个tuple以及由这个tuple所产生的所有的子tuple都被成功处理.           如果任一个消息在timeout所指定的时间内没有完成处理,那这个tuple就失败了. 二.原理:              acker并不会为每个tuple都分配内存空间来完成跟踪,而是利用了一个非常巧妙的算法,这个算法只需使用恒定的20字节就可以完成整个tuple树的

Understanding the Internal Message Buffers of Storm Jun 21st, 2013 Table of Contents Internal messaging within Storm worker processes Illustration Detailed description Worker processes Executors Where to go from here How to configure Storm's internal

这篇文件翻译自 http://www.michael-noll.com/blog/2013/06/21/understanding-storm-internal-message-buffers/ 当进行Storm调优时,理解Storm内部消息队列的配置十分有帮助.这篇文件将说明在Storm 0.8/0.9版本中一个Worker内部的消息通信. Storm Worker进程内部消息传输 这里所说的“内部消息”是指单台节点上的一个Worker进程内部的消息.这种通信依赖于Storm内部各种 LMAX

在大数据时代,数据规模变得越来越大.由于数据的增长速度和非结构化的特性,常用的软硬件工具已无法在用户可容忍的时间内对数据进行采集.管理和处理.本文主要介绍如何在阿里云上使用Kafka和Storm搭建大规模消息分发和实时数据流处理系统,以及这个过程中主要遭遇的一些挑战.实践主要立足建立一套汽车状态实时监控系统,可以在阿里云上立即进行部署. 实时大数据处理利器——Storm和Kafka 大数据时代,随着可获取数据的渠道增多,比如常见的电子商务.网络.传感器的数据流.太空数据等,数据规模也变得越来越大

英文原文地址 中英文对照地址 History of Apache Storm and lessons learned --项目创建者 Nathan Marz Apache Storm 最近成为了ASF的顶级项目,这对于该项目和我个人而言是一个重大的里程碑.很难想像4年前Storm只是我脑海中的一个想法,但现在却成为了一个有着大社区支持并被无数企业使用的繁荣项目.在此我将在本文中回首Storm的成长历程及其经验教训. 我会根据我当初必须要克服的主要挑战来涵盖Storm历史的相关主题.本文前25%是

阅读目录 Storm来源 初探 再探 构建第一个版本 被Twitter收购 开源的Storm 发布之后 Storm的技术演进 构建开发者社区版 离开Twitter 提交到Apache Apache孵化 结论 Apache Storm 最近成为了ASF的顶级项目,这对于该项目和我个人而言是一个重大的里程碑.很难想像4年前Storm只是我脑海中的一个想法,但现在却成为了一个有着大社区支持并被无数企业使用的繁荣项目.在此我将在本文中回首Storm的成长历程及其经验教训. 我会根据我当初必须要克服的主要

storm保证从spout发出的每个tuple都会被完全处理.这篇文章介绍storm是怎么做到这个保证的,以及我们使用者怎么做才能充分利用storm的可靠性特点. 一个tuple被”完全处理”是什么意思? 就如同蝴蝶效应一样,从spout发射的一个tuple可以引起其它成千上万个tuple因它而产生, 想想那个计算一篇文章中每个单词出现次数的topology. 帮助 1 2 3 4 5 6 7 8 9 TopologyBuilder builder = new TopologyBuilder()

Storm入门教程 1. Storm基础 Storm Storm主要特点 Storm基本概念 Storm调度器 Storm配置 Guaranteeing Message Processing(消息处理保障机制) 消息的"完整性处理" 在消息得到完整性处理后或处理失败后会发生什么 Storm 的可靠性 API 在 tuple 可以被重新处理的前提下,如何使应用正确运行 Storm 是以怎样以高效的方式实现可靠性 调整可靠性 Daemon Fault Tolerance(守护线程容错机制)

Storm入门教程 1. Storm基础 Storm Storm主要特点 Storm基本概念 Storm调度器 Storm配置 Guaranteeing Message Processing(消息处理保障机制) Daemon Fault Tolerance(守护线程容错机制) 理解Storm拓扑的并行 Tutorial Local模式 在生产环境中运行Topologies Storm Storm是一个免费开源的分布式实时计算系统.Storm令无边界的流数据计算变得容易,弥补了Hadoop批处理所

Guaranteeing Message Processing Storm保证每一个tuple被完全处理.Strom中一个核心的机制是它提供了一种跟踪tuple血统的能力,它使用了一种十分有效的方式跟踪topology中的tuple. Storm中最基本的抽象是提供了至少一次(at-least-once)处理的保证,当你使用队列系统的时候也可以提供相同的保证. Messages are only replayed when there are failures.(消息只有在失败的时候才会被重新投

一.前言 消息队列中间件(简称消息中间件)是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成.通过提供消息传递和消息排队模型,它可以在分布式环境下提供应用解耦.弹性伸缩.冗余存储.流量削峰.异步通信.数据同步等等功能,其作为分布式系统架构中的一个重要组件,有着举足轻重的地位. 目前开源的消息中间件可谓是琳琅满目,能让大家耳熟能详的就有很多,比如ActiveMQ.RabbitMQ.Kafka.RocketMQ.ZeroMQ等.不管选择其中的哪一款,都会有用

0. 背景 最近我在做流式实时分布式计算系统的架构设计,而正好又要参加CSDN博文大赛的决赛.本来想就写Spark源码分析的文章吧.但是又想毕竟是决赛,要拿出一些自己的干货出来,仅仅是源码分析貌似分量不够.因此,我将最近一直在做的系统架构的思路整理出来,形成此文.为什么要参考Storm和Spark,因为没有参照效果可能不会太好,尤其是对于Storm和Spark由了解的同学来说,可能通过对比,更能体会到每个具体实现背后的意义. 本文对流式系统出现的背景,特点,数据HA,服务HA,节点间和计算逻辑间

kafka原理简介并且与RabbitMQ的选择 kafka原理简介,rabbitMQ介绍,大致说一下区别 Kafka是由LinkedIn开发的一个分布式的消息系统,使用Scala编写,它以可水平扩展和高吞吐率而被广泛使用.目前越来越多的开源分布式处理系统如Cloudera.Apache Storm.Spark都支持与Kafka集成. 消息的发布描述为producer,消息的订阅描述为consumer,将中间的存储阵列称作broker(代理).kafka是linkedin用于日志处理的分布式消息队

转自http://blog.csdn.net/zhangzhebjut/article/details/38467145 一 可靠性简介 Storm的可靠性是指Storm会告知用户每一个消息单元是否在一个指定的时间(timeout)内被完全处理.完全处理的意思是该MessageId绑定的源Tuple以及由该源Tuple衍生的所有Tuple都经过了Topology中每一个应该到达的Bolt的处理. 注: timetout 可以通过Config.TOPOLOGY_MESSAGE_TIMEOUT_SE

转自:http://xumingming.sinaapp.com/127/twitter-storm如何保证消息不丢失/ storm保证从spout发出的每个tuple都会被完全处理.这篇文章介绍storm是怎么做到这个保证的,以及我们使用者怎么做才能充分利用storm的可靠性特点. 一个tuple被”完全处理”是什么意思? 就如同蝴蝶效应一样,从spout发射的一个tuple可以引起其它成千上万个tuple因它而产生, 想想那个计算一篇文章中每个单词出现次数的topology. Topolog

一.前言 1.这一文开始进入Storm流式计算框架的学习 二.Storm简介 1.Storm与Hadoop的区别就是,Hadoop是一个离线执行的作业,执行完毕就结束了,而Storm是可以源源不断的接受数据源,不停的对数据进行处理,而数据就行水流一样不停的流进来,经过处理,再将结果存入数据库或者做其他用途 2.基础概念 (1)Tuple(元组):数据流传递的基本单元,相当于数据的流动通过Tuple作为对象来传递 (2)Spout(龙卷):相当于数据源,通过重写nextTuple()方法,源源不断