1. 问题描述 rocketmq 生产者发消息正常 mq后台也可以看到发出的消息 但是消费者一直没消费 好像订阅没成功 2. 问题排查 通过上图查看 确实没有检测到订阅者 3. 问题解决 线上环境是 两台机器 共四个实例 项目中订阅了两个不同地址不同topic的mq 然后那个instanceName会有命名冲突 ip@进程id 重新修改instanceName的value //设置instanceName defaultMQPushConsumer.setInstanceName(System.

broker 1. broker的启动 brker的启动 Broker向namesrv注册 1. 获取namesrv的地址列表(是乱序的) 2. 遍历向每个namesrv注册topic的配置信息topicconfig Topic在broker文件上的存储json格式 "TopicTest":{ "perm":6, "readQueueNums":8, "topicFilterType":"SINGLE_TAG&quo

一.RocketMQ简介: RocketMQ是一款分布式.队列模型的消息中间件,具有以下特点: 1.支持严格的消息顺序: 2.支持Topic与Queue两种模式: 3.亿级消息堆积能力: 4.比较友好的分布式特性: 5.同时支持Push与Pull方式消费消息: 官网链接: rocketmq下载地址: https://github.com/alibaba/RocketMQ/releases rocketmq github:   https://github.com/alibaba/RocketMQ

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

-------------------------------------------------------------------------------------------- 一.Rocketmq简介: -------------------------------------------------------------------------------------------- RocketMQ是一款分布式.队列模型的消息中间件,具有以下特点:1.支持严格的消息顺序:2.支持T

在RocketMQ中,使用BrokerStartup作为启动类,相较于NameServer的启动,Broker作为RocketMQ的核心可复杂得多 [RocketMQ中NameServer的启动源码分析] 主函数作为其启动的入口: public static void main(String[] args) { start(createBrokerController(args)); } 首先通过createBrokerController方法生成Broker的控制器BrokerControll

目录 1.案情回顾 1.1 集群现状 1.2.RocketMQ 在线扩容队列 1.3 消息发送 2.问题暴露 3.问题分析 4.问题复盘 消息组接到某项目组反馈,topic 在扩容后出现部分队列无法被消费者,导致消息积压,影响线上业务? 考虑到该问题是发送在真实的线上环境,为了避免泄密,本文先在笔者的虚拟机中来重现问题. @(本节目录) 1.案情回顾 1.1 集群现状 集群信息如下: 例如业务主体名 topic_dw_test_by_order_01 的路由信息如图所示: 当前的消费者信息: b

一.MQ存储分类 MQ存储主要分为以下三类: 文件系统:RocketMQ/Kafka/RabbitMQ 关系型数据库DB:ActiveMQ(默认采用的KahaDB做消息存储)可选用JDBC的方式来做消息持久化 分布式KV存储:ZeroMQ 对比: 存储效率, 文件系统>分布式KV存储>关系型数据库DB 易于实现和快速集成,关系型数据库DB>分布式KV存储>文件系统,但是性能会下降很多 二.RocketMQ存储概要 (一)存储文件 RocketMQ文件存储在rocketmq文件夹下的

一.消息队列概述 1.1.消息队列由来 在运维场景中,我们经常会存在如下场景:一旦出现S1异常,C1将因为S1的影响而异常(C为客户端,s为服务端) 当然可以通过添加多个S的方式,实现高可用.但这样会变得难以维护,每增加一个S所有的C都要进行调整,增加了耦合性(软件开发强调高内聚低耦合) 可以通过在C和S之间添加负载均衡来达到降低耦合度的效果,但是在流量高峰期C1收到的压力,仍然会传递到后端S.如果S处理处理不过来可能就会导致异常(一般情况下前端的接收请求的速度是较快的,但是后端处理请求的速录会

Remoting2. 通信层底层传输协议 RocketMq服务器与客户端通过传递RemotingCommand来交互,通过NettyDecoder,对RemotingCommand进行协议的编码与解码 协议格式 <length> <header length> <header data> <bodydata> 1        2               3          4 协议分4部分,含义分别如下 1.大端4个字节整数,等于2.3.4长度总和

consumer 1.启动 有别于其他消息中间件由broker做负载均衡并主动向consumer投递消息,RocketMq是基于拉模式拉取消息,consumer做负载均衡并通过长轮询向broker拉消息. Consumer消费拉取的消息的方式有两种 1. Push方式:rocketmq已经提供了很全面的实现,consumer通过长轮询拉取消息后回调MessageListener接口实现完成消费,应用系统只要MessageListener完成业务逻辑即可 2. Pull方式:完全由业务系统去控制,

producer  producer 1.启动流程 Producer如何感知要发送消息的broker即brokerAddrTable中的值是怎么获得的, 1. 发送消息的时候指定会指定topic,如果producer集合中没有会根据指定topic到namesrv获取topic发布信息TopicPublishInfo,并放入本地集合 2. 定时从namesrv更新topic路由信息, Producer与broker间的心跳 Producer定时发送心跳将producer信息(其实就是procdue

分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 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 工程,进入/RocketMQ/bin   在该目录下有个 mqadmin 脚本 .  查看帮助:   在 mqadmin 下可以查看有哪些命令    a: 查看具体命令的使用 : sh mqadmin      b: sh mqadmin help 命令名称   例如,查看 updateTopic 的使用 sh mqadmin help updateTopic 2. 关闭nameserver和所有的broker:    进入到bin下:     sh mqshutdo

报错: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'warningProducer': Invocation of init method failed; nested exception is java.lang.ExceptionInInitializerError at org.springframework.beans.factory.annotation.

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

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

引言 分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦.现在开源的消息中间件有很多,前段时间我们自家的产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注. 那么,消息中间件性能究竟哪家强? 带着这个疑问,我们中间件测试组对常见的三类消息产品(Kafka.RabbitMQ.RocketMQ)做了性能比较. Kafka是LinkedIn开源的分布式发布-订阅消息系统,目前归属于Apache定级项目.Kafka主要特点是基于Pull的模式来处理消息消费,追求

引言 前几期的评测中,我们对比了Kafka和RocketMQ的吞吐量和稳定性,本期我们要引入一个新的评测标准--软件可靠性. 何为"可靠性"? 先看下面这种情况:有A,B两辆越野汽车,在城市的周边地区均能很好应对泥泞的路况.当一同开去穿越西藏,A车会因为西藏本地的汽油不达标,导致油路受阻无法点火,而B车顺利完成了穿越.因此我们说,B车的可靠性比A车高. 何为"软件可靠性"? "软件的可靠性"就是考察软件在各种异常突发的情况下的应对能力.常见的软件