rocketMq官网 http://rocketmq.apache.org/ rocketMq逻辑概念介绍 rocketMq逻辑图 备注:    改图片分享自李占卫的网上家园 说明: 在rocketMq的中核心4组件为namesrv.broker.consumer.producer. broker:消息存储中心,主要用来存储消息并通过namesrv对外提供服务. namesrv:无状态的注册中心,功能用来保存broker的相关的元信息并提供给producer在发送消息过程中和提供给consume

介绍 rocketmq 框架与基本概念 1. 概念 1.1 namesrv(name server) 记录了 broker 集群信息,消息队列的信息以及 key-value 配置,见 RouteInfoManager 和 KVConfigManager. 可以由多个 namesrv 实例组成集群,但相互独立,没有信息交换. 1.2 broker 核心组件,负责存储所有的消息相关信息 支持主从模式 支持 master 写操作,只有当 master 读压力高于某个点(消息堆积),才会将读压力转给 s

DefaultMessageStore 消息的存储和提取. 相对重要的两个方法: 消息存储 PutMessageResult putMessage(MessageExtBrokerInner msg) 消息获取 GetMessageResult getMessage(final String group, final String topic, final int queueId, final long offset, final int maxMsgNums, final Subscripti

RocketMQ(2)-Docker集群部署RocketMQ =前言= 1.因为自己只买了一台阿里云服务器,所以RocketMQ集群都部署在单台服务器上只是端口不同,如果实际开发,可以分别部署在多台服务器上. 2.这里有关 Broker 和 NameServer 分别都做了了集群部署(各部署两个),且BroKer是按两主进行部署. 之所以选用Docker部署主要还是考虑 :通过Docker部署RocketMQ集群更快速,而且对系统的资源利用更好! 之前有写过Liunx如何部署Docker的博客:

目录 RocketMQ介绍 RocketMQ概念 为什么要用RocketMQ? 异步解耦 削峰填谷 分布式事务最终一致性 数据分发 RocketMQ架构 RocketMQ消息类型 普通消息 顺序消息 定时消息 事务消息 最佳实践 消息重试 消息过滤 消费模式 消费幂等 本地事务消息封装 参考代码 RocketMQ 介绍 Apache RocketMQ 是一款 低延迟.高并发.高可用.高可靠的分布式消息中间件.消息队列 RocketMQ 可为分布式应用系统提供异步解耦和削峰填谷的能力,同时也具备互

RocketMQ基本概念 一.生产者 生产者发送业务系统产生的消息给broker.RocketMQ提供了多种发送方式:同步的.异步的.单向的. 1.1 生产者组 具有相同角色的生产者被分到一组.假如原始的生产者在事务后崩溃,broker会联系 同一生产者组中的不同生产者实例,继续提交或回滚事务. 二.消费者 一个消费者从broker拉取信息,并将信息返还给应用.为了我们应用的正确性,提供了两种消费者类型: 拉式消费者:拉式消费者从broker拉取消息,一旦一批消息被拉取,用户应用系统将发起消费过

基本概念 ProducerGroup 通常具有同样属性(处理的消息种类-topic.以及消息处理逻辑流程—分布式多个客户端)的一些producer可以归为同一个group.在事务消息机制中,如果某条发送某条消息的producer-A宕机,使得事务消息一直处于PREPARED状态并超时,则broker会回查 同一个group的其他producer,确认这条消息应该commit还是rollback. ConsumerGroup 具有同样逻辑消费同样消息的consumer,可以归并为一个group.同

为什么选择RocketMQ 我们来看看官方回答: “我们研究发现,对于ActiveMQ而言,随着越来越多的使用queues和topics,其IO成为了瓶颈.某些情况下,消费者缓慢(消费能力不足)还会拖慢生产者(造成消息阻塞).虽然我们做了最大努力进行优化:节流.断路器或者回退,但是并不能进行优雅的扩展.因此我们开始专注于使用时下非常流行的kafka,但是仍然不能满足我们的要求,如低延迟和高可靠性,详情见这里.在这样的背景下,我们决定开发一个新的消息中间件来处理一系列广泛的使用场景,包括从传统的发

Topic 一类消息的集合,RocketMQ的基本订阅单位 部署结构 Name Server Name Server 为 producer 和 consumer 提供路由信息. 相对来说,nameserver的稳定性非常高.原因有二: nameserver互相独立,彼此没有通信关系,单台nameserver挂掉,不影响其他nameserver,即使全部挂掉,也不影响业务系统使用.无状态 nameserver不会有频繁的读写,所以性能开销非常小,稳定性很高. Broker Server 代理服务器

RocketMQ是阿里出品的一款开源的消息中间件,让其声名大噪的就是它的事务消息的功能.在企业中,消息中间件选择使用RocketMQ的还是挺多的,这一系列的文章都是针对RocketMQ的,咱们先从RocketMQ的一些基本概念和环境的搭建开始聊起. RocketMQ由4部分组成,分别是:名称服务(Name Server).消息队列(Brokers).生产者(producer)和消费者(consumer).这4部分都可以进行水平扩展,从而避免单点故障,如下图, 这是RocketMQ官网上的一张图,

由于篇幅原因,本次的源码分析只限于Producer侧的发送消息的核心逻辑,我会通过流程图.代码注释.文字讲解的方式来对源码进行解释,后续应该会专门开几篇文章来做源码分析. 这篇博客聊聊关于RocketMQ相关的东西,主要聊的点有RocketMQ的功能使用.RocketMQ的底层运行原理和部分核心逻辑的源码分析.至于我们为什么要用MQ.使用MQ能够为我们带来哪些好处.MQ在社区有哪些实现.社区的各个MQ的优劣对比等等,我在之前的文章<消息队列杂谈>已经聊过了,如果需要了解的话可以回过头去看看.

分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性以及其实现原理 一.顺序消息 消息有序指的是一类消息消费时,能按照发送的顺序来消费.例如:一个订单产生了 3 条消息,分别是订单创建.订单付款.订单完成.消费时,要按照这个顺序

1.生产者: package com.ebways.mq.test.mq; import com.alibaba.rocketmq.client.exception.MQClientException; import com.alibaba.rocketmq.client.producer.DefaultMQProducer; import com.alibaba.rocketmq.client.producer.SendResult; import com.alibaba.rocketmq.c

引言 上期我们对比了RocketMQ和Kafka在多Topic场景下,收发消息的对比测试,RocketMQ表现稳定,而Kafka的TPS在64个Topic时可以保持13万,到了128个Topic就跌至0.85万,导致无法完成测试.我们不禁要问: 为什么看不到Kafka性能暴跌的趋势呢? 今天的测试,就来排查一下这个问题,然后验证一下两个系统对外服务的稳定性.本次测试,要引入"稳定性测试"这个概念,那什么是稳定性测试呢?我们先来看一下定义: 稳定性测试:测试系统的长期稳定运行能力.在系统

引言 上一期我们对比了三类消息产品(Kafka.RabbitMQ.RocketMQ)单纯发送小消息的性能,受到了程序猿们的广泛关注,其中大家对这种单纯的发送场景感到并不过瘾,因为没有任何一个网站的业务只有发送消息.本期,我们就来模拟一个真实的场景: 消息的发送和订阅一定是共存的 要支持多个订阅端订阅自己感兴趣的消息鉴于上一期Kafka和RocketMQ的指标和关注度很高,本期我们将只针对这两个产品,对比在上述场景中,究竟谁更胜一筹.在正式开始测试之前,首先要向大家明确2个概念: Topic为何物

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件,使用Mysql作为消息存储媒介,可完全水平扩容,为了进一步降低成本,我们认为存储部分可以进一步优化,2011年初,Linkin开源了Kafka这个优秀的消息中间件,淘宝中间件团队在对Kafka做过充分Review之后,Kafka无限消息堆积,高效的持久化速度吸引了我们,但是同时发现这个消息系统主要定位于日志传输,对于使用在淘宝交易.订单.充值等场景下还有诸多特性不满足,为此我们重新用Java语言编写了RocketMQ,定位于非日志的可

      转自:https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafka 淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件,使用Mysql作为消息存储媒介,可完全水平扩容,为了进一步降低成本,我们认为存储部分可以进一步优化,2011年初,Linkin开源了Kafka这个优秀的消息中间件,淘宝中间件团队在对Kafka做过充分Review之后,Kafka无限消息堆积,高效的持久化速度吸引了我们,但是同时发现这个消息系统主要定位于日志传输

1.RocketMQ中的专业术语 Topic topic表示消息的第一级类型,比如一个电商系统的消息可以分为:交易消息.物流消息...... 一条消息必须有一个Topic. Tag Tag表示消息的第二级类型,比如交易消息又可以分为:交易创建消息,交易完成消息..... 一条消息可以没有Tag.RocketMQ提供2级消息分类,方便大家灵活控制. Queue 一个topic下,我们可以设置多个queue(消息队列).当我们发送消息时,需要要指定该消息的topic.RocketMQ会轮询该topi

RocketMQ RocketMQ是一款分布式.队列模型的消息中间件,具有以下特点:能够保证严格的消息顺序 能够保证严格的消息顺序 提供丰富的消息拉取模式 高效的订阅者水平扩展能力 实时的消息订阅机制 亿级消息堆积能力 专业术语 1.Producer:消息生产者,负责产生消息,一般有业务系统负责产生消息 2.Consumer:消息消费者,负责消费消息,一般是后台系统负责异步消费 3.PushConsumer:Consumer的一种,应用通常向Consumer注册一个Listener监听器,Con

一.  环境搭建 需要jdk1.6(以上) 64bit, maven, eclipse 二.  RocketMQ项目下载 项目地址:https://github.com/alibaba/RocketMQ,将下载的RocketMQ-master放到eclipse工作空间中 三. 将RocketMQ-master导入到eclipse中 将项目导入eclipse,如下图 2. 在我下载的RocketMQ-master的pom.xml文件的parent有个问题,默认如下: <parent> <g