rocketmq

Topic 主题，从逻辑上讲一个Topic就是一个Queue，即一个队列；从存储上讲，一个Topic存储了一类相同的消息，是一类消息的集合。比如一个名称为trade.order.queue的Topic里面存的都是订单相关的消息。 Partition 分区。分区是存在于服务端，内部保持顺序、且顺序不可变更的一个队列，用于存储消息。分区可能不应该出现在消息领域内，在使用消息中间件发送和消费时，实际上用户是感受不到分区这个概念的。下面这幅图便于大家去理解分区： 一个Topic存储消息时会分为多个Partition，每个Partition内消息是有顺序的。至于为什么需要将Topic划分成按照Partition存储，在以后设计和实现部分会解释。 Producer 生产者，消息的生产方，一般由业务系统负责产生消息。 Producer负责决定将消息发送到哪个Topic的那个Partition。 Consumer 消费者，消息的消费方，一般是后台系统负责异步消费消息。 Consumer订阅Topic，消费Topic内部的消息。 Broker 消息的存储者，一般也称为Server，在JMS中叫Provider，在RocketMQ（阿里开源的消息中间件）中叫Broker。 NameServer NameServer其实不是消息中间件的概念了

1、RocketMQ简单介绍 RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成，如下图所示 所有的集群都具有水平扩展能力，无单点障碍。 NameServer以轻量级的方式提供服务发现和路由功能，每个NameServer存有全量的路由信息，提供对等的读写服务，支持快速扩缩容。 Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型，具备多副本容错机制（2副本或3副本）、强大的削峰填谷以及上亿级消息堆积能力，同时可严格保证消息的有序性。除此之外，Broker还提供了同城异地容灾能力，丰富的Metrics统计以及告警机制。这些都是传统消息系统无法比拟的。 Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。 Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制，满足大多数消费场景。 2、RocketMQ中的专业术语 Topic topic表示消息的第一级类型，比如一个电商系统的消息可以分为：交易消息、物流消息...... 一条消息必须有一个Topic。 Tag Tag表示消息的第二级类型，比如交易消息又可以分为：交易创建消息，交易完成消息.....

1.概述 本篇文章会尽力全面的介绍RocketMQ和Kafka各个关键点的比较，希望大家读完能有所收获。 RocketMQ前身叫做MetaQ, 在MeataQ发布3.0版本的时候改名为RocketMQ，其本质上的设计思路和Kafka类似，但是和Kafka不同的是其使用Java进行开发，由于在国内的Java受众群体远远多于Scala，所以RocketMQ是很多以Java语言为主的公司的首选。同样的RocketMQ和Kafka都是Apache基金会中的顶级项目，他们社区的活跃度都非常高，项目更新迭代也非常快。 2.入门实例 2.1 生产者 public class Producer { public static void main(String[] args) throws MQClientException, InterruptedException { DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName"); producer.start(); for (int i = 0; i < 128; i++) try { { Message msg = new Message("TopicTest", "TagA", "OrderID188", "Hello world".getBytes

这节课我们来学习消息队列中像队列、主题、分区等基础概念。这些基础的概念，就像我们学习一门编程语言中的基础语法一样，你只有搞清楚它们，才能进行后续的学习。 如果你研究过超过一种消息队列产品，你可能已经发现，每种消息队列都有自己的一套消息模型，像队列（Queue）、主题（Topic）或是分区（Partition）这些名词概念，在每个消息队列模型中都会涉及一些，含义还不太一样。 为什么出现这种情况呢？因为没有标准。曾经，也是有一些国际组织尝试制定过消息相关的标准，比如早期的 JMS 和 AMQP。但让人无奈的是，标准的进化跟不上消息队列的演进速度，这些标准实际上已经被废弃了。 那么，到底什么是队列？什么是主题？主题和队列又有什么区别呢？想要彻底理解这些，我们需要从消息队列的演进说起。 主题和队列有什么区别？ 在互联网的架构师圈儿中间，流传着这样一句不知道出处的名言，我非常认同和喜欢：好的架构不是设计出来的，而是演进出来的。 现代的消息队列呈现出的模式，一样是经过之前的十几年逐步演进而来的。 最初的消息队列，就是一个严格意义上的队列。在计算机领域，“队列（Queue）”是一种数据结构，有完整而严格的定义。在维基百科中，队列的定义是这样的： 队列是先进先出（FIFO, First-In-First-Out）的线性表（Linear List）。在具体应用中通常用链表或者数组来实现

背景 开源版的RocketMQ只提供了18个层级的消息队列延时，这个功能在开源版中显得特别鸡肋，但是在阿里云中的RocketMQ却提供了支持40天之内任意秒级延时队列，果然有些功能你只能充钱才能拥有。当然你或许想换一个开源的消息队列，在开源社区中消息队列延时消息很多都没有被支持比如：RabbitMQ,Kafka等，都只能通过一些特殊方法才能完成延时的功能。为什么这么多都没有实现这个功能呢？是因为技术难度比较复杂吗？接下来我们分析一下如何才能实现一个延时消息。 RocketMQ消息产生后，生产者希望在间隔一段时间后被消费的场景可以使用定时消息，RocketMQ目前不支持自定义延迟时间，但可以指定延迟等级，可以选择18个延迟等级，分别是对应延迟时间是1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。 RocketMQ的延迟消息主题是SCHEDULE_TOPIC_XXXX，18个延迟级别对应18个消息队列，当消息投递到broker后，如果消息中指定了延迟等级（DelayTimeLevel），消息topic会更改为SCHEDULE_TOPIC_XXXX，queueId更改为延迟等级对应的消息队列，原有的topic和queueId会放到msg属性的REAL_TOPIC与REAL_QID中。 本地延时

1、配置文件 1、yml配置文件 rocketmq: #mq配置 producer: iseffect: true type: default # (transaction,default) transaction:TransactionMQProducer; default:DefaultMQProducer groupName: testzjlGroup topicName: test_topic namesrvAddr: 192.168.244.128:9876 consumer: iseffect: true type: default # (transaction,default) transaction:TransactionMQProducer; default:DefaultMQProducer groupName: testzjlGroup topicName: test_topic namesrvAddr: 192.168.244.128:9876 2、对应的java类 package com.gofun.customer.mq; import org.springframework.boot.context.properties.ConfigurationProperties; @ConfigurationProperties(prefix =

一、现象 mqcloud持续发送topic为digg-topic的消费者digg-group发生偏移量错误的预警邮件，详细预警如下： 即：digg-group请求从偏移量 156798 开始消费，但是broker上最小的消息偏移量是 172289 ，也就是说， 消费者想请求消费的消息，在broker上已经不存在了。 解释：rocketmq会将此种情况当做一个事件消息发送到内置的topic：OFFSET_MOVED_EVENT中，mqcloud会订阅并消费该topic，并会以固定频率进行预警。 二、mqcloud监控情况 顺着预警邮件的链接，到mqcloud里看下消费者的具体情况，发现digg-group消费有堆积，详细如下： 点开查看每个客户端的消费情况，定位到某个机器消费有堆积： 三、broker表现 找到对应的broker的某个实例，查看broker.log日志，发现很多类似如下的日志： 2019-01-18 19:24:01 INFO PullMessageThread_49 - the request offset too small. group=digg-group, topic=digg-topic, requestOffset=156798, brokerMinOffset=172289, clientIp=/10.*.*.*:54437 2019-01-18 19

环境版本 操作系统：Linux/Unix java版本：JDK1.8+ Maven 3.2.x Git 1 安装JDK 此处省略 2 下载发行版 点击 此处 ，下载4.6.0源发行版 > unzip rocketmq - all - 4.6 .0 - source - release . zip > cd rocketmq - all - 4.6 .0 / > mvn - Prelease - all - DskipTests clean install - U > cd distribution / target / apache - rocketmq 2.1 启动Name Server > nohup sh bin / mqnamesrv & > tail - f ~ / logs / rocketmqlogs / namesrv . log 2.2 启动Broker > nohup sh bin / mqbroker - n localhost : 9876 & > tail - f ~ / logs / rocketmqlogs / broker . log 2.3 发送和接收消息 在发送/接收消息之前，我们需要告诉客户端名称服务器的位置。RocketMQ提供了多种方法来实现这一目标。为简单起见，我们使用环境变量 NAMESRV_ADDR > export NAMESRV

本文将深入剖析rocketmq为什么选择自己开发NameServer，而不是选择类似于ZK这样的开源组件。同时对rocketmq的路由注册、路由发现、路由剔除进行剖析。并通过结合核心源码，对笔者的观点进行验证。同时对不同类型消息的重试机制，以及客户端选择nameserver的策略进行深入讲解。 文章第一部分是name server在rocketmq整体架构中的作用，熟悉的同学可以直接跳过。 1 NameServer的作用 Name Server 是专为 RocketMQ 设计的轻量级名称服务，具有简单、可集群横吐扩展、无状态，节点之间互不通信等特点。整个Rocketmq集群的工作原理如下图所示： 可以看到，Broker集群、Producer集群、Consumer集群都需要与NameServer集群进行通信： Broker集群 Broker用于接收生产者发送消息，或者消费者消费消息的请求。一个Broker集群由多组Master/Slave组成，Master可写可读，Slave只可以读，Master将写入的数据同步给Slave。每个Broker节点，在启动时，都会遍历NameServer列表，与每个NameServer建立长连接，注册自己的信息，之后定时上报。 Producer集群 消息的生产者，通过NameServer集群获得Topic的路由信息，包括Topic下面有哪些Queue

高性能 存储原理 零拷贝 数据结构与存储逻辑 刷盘策略 长轮询PULL RocketMQ的Consumer都是从Broker拉消息来消费，但是为了能做到实时收消息，RocketMQ使用长轮询方式，可以保证消息实时性同Push方式一致。 这里需要注意的是，长轮询与长连接是两个不同的概念。长轮询表示，当客户端的一个请求达到服务端时，若此时没有可供返回的数据，那么这个连接会一直保持，当有可供返回的数据时，返回数据并关闭连接，之后客户端立即再创建一个连接向服务端请求数据。而长连接表示一个连接被永久保持。 高可用 来源： https://www.cnblogs.com/xiaogangfan/p/12019091.html