消息中间件：谈一谈 RocketMQ 的技术架构

延迟消息是实际开发中一个非常有用的功能，本文第一部分从整体上介绍秒级精度延迟消息的实现思路，在第二部分结合RocketMQ的延迟消息实现，进行细致的讲解，点出关键部分的源码。第三步介绍延迟消息与消息重试的关系。Broker判断这是一个延迟消息后，将其通过临

用过 MQ 的同学，可能会遇到过消息堆积的问题。而我最近也踩上了这个坑，但是发现结果竟然是这么一个意料之外的原因而导致的。那一晚月和风高，我正准备踏上回家的路，突然收到告警短信轰炸！于是乎赶回公司赶紧打开电脑，登上 RocketMQ 后台查看

整体架构最近看到了我在Github上写的rabbitmq-examples陆续被人star了，就想着写个rocketmq-examples。对rabbitmq感兴趣的小伙伴可以看我之前的文章。下面把RocketMQ的各个特性简单介绍一下，这样在用的时候心里

此时，为了提高用户体验和吞吐量，其实可以异步地调用系统B、C、D的接口。所以，我们可以通过引入消息中间件，再系统A执行完后将数据写入到消息队列中直接返回，而BCD系统则负责监听执行。通过以上分析可知，消息中间件最佳选型为RocketMQ。

对于RocketMQ而言，感觉官方提供的东西还是可以的：https://github.com/apache/rocketmq/tree/master/docs/cn

　　RocketMq producer 在发送一条消息时候，从 producer --nameSrv -- Broker 中间经过了什么样子的数据交互。从NameSrv 中获取topic 配置的相关信息，比如 broker 地址，队列数 之类的。

前面的章节，我们已经把RocketMQ的环境搭建起来了，是一个两主两从的异步集群。接下来，我们就看看怎么去使用RocketMQ，在使用之前，先要在NameServer中创建Topic，我们知道RocketMQ是基于Topic的消息队列，在生产者发送消息的时

折腾了好长时间才写这篇文章，顺序消费，看上去挺好理解的，就是消费的时候按照队列中的顺序一个一个消费；而并发消费，则是消费者同时从队列中取消息，同时消费，没有先后顺序。RocketMQ也有这两种方式的实现，但是在实践的过程中，就是不能顺序消费，好不容易能够实

今天要给大家介绍RocketMQ中的两个功能，一个是“广播”，这个功能是比较基础的，几乎所有的mq产品都是支持这个功能的；另外一个是“延迟消费”，这个应该算是RocketMQ的特色功能之一了吧。广播是把消息发送给订阅了这个主题的所有消费者。首先，消费者端的

RocketMQ是阿里出品的一款开源的消息中间件，让其声名大噪的就是它的事务消息的功能。在企业中，消息中间件选择使用RocketMQ的还是挺多的，这一系列的文章都是针对RocketMQ的，咱们先从RocketMQ的一些基本概念和环境的搭建开始聊起。Rock

　　要了解rocketMq 需要知道 数据在 rocketMq 中 是如何进行传输，在底层的结构到底是一个什么亚子，这个需要我们对Netty 对字符编解码有一些了解。　　我们从生产者发送消息，broker 接收消息 为例，来开展底层对消息结构。　　1. 如

然后执行‘start mqnamesrv.cmd’，启动NAMESERVER。成功后会弹出提示框，此框勿关闭。#set it false if you don‘t want use dashboard.default true. #set the mess

RocketMQ有一个对其扩展的开源项目incubator-rocketmq-externals，这个项目中有一个子模块叫rocketmq-console，这个便是管理控制台项目了，先将incubator-rocketmq-externals拉到本地，因为

前面的章节，我们已经把RocketMQ的环境搭建起来了，是一个两主两从的异步集群。接下来，我们就看看怎么去使用RocketMQ，在使用之前，先要在NameServer中创建Topic，我们知道RocketMQ是基于Topic的消息队列，在生产者发送消息的时

RocketMQ事务消息是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。Producer 已经把消息成功发送到

偶尔推出一个优惠活动时，请求量极速上升。看了几个招聘网站，提到较多的消息队列有：RabbitMQ、RocketMQ、Kafka 以及 Redis 的消息队列和发布订阅模式。在高可用环境中，Kafka 需要部署多台，避免 Kafka 宕机后，服务无法访问。K

Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。Broker部署相对复杂，Broker分为Master和Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master和Slave

我觉得这个问题问得很频繁，而且非常经典，在这里我就以 Kafka 为例子，说说我对 Kafka 顺序消息的一些理解吧，如有理解不对的地方麻烦留言指点一下。针对以上第二点，下面盘点一下 Kafka 集群中有哪些意外情况会打乱消息的顺序。

上一节消息重试里面提到了重试的消息可以被延时消费，其实除此之外，用户发送的消息也可以指定延时时间，然后在指定延时时间之后投递消息，然后被consumer消费。broker收到消息在准备将消息写入存储的时候，判断是延时消息则更改Message的topic为延

通常一个消息队列需要掌握的知识点有Topic（主体）、Producer（生产者）、Consumer（消费者）、Queue（队列）、Delivery Semantics. 蛋疼的是不同的消息队列关于这些名词叫法不一样，含义也不是很精确。所以阿里起了一个项目O

　　RabbitMQ是一个开源的消息代理软件，它的核心作用就是创建消息队列，异步接收和发送消息，MQ的全程是：Message Queue中文的意思是消息队列。　　●延迟处理：可以进行事件后置，比如订单超时业务，用户下单30分钟未支付取消订单；　　现在市面上

本文将对 RocketMQ-Exporter 的设计实现做一个简单的介绍，读者可以通过本文了解到 RocketMQ-Exporter 的实现过程，以及通过 RocketMQ-Exporter 来搭建自己的 RocketMQ 监控系统。Exporter 将监

请求kernel直接把disk的data传输给socket，而不是通过应用程序传输。Zero copy大大提高了应用程序的性能，减少不必要的内核缓冲区跟用户缓冲区间的拷贝，从而减少CPU的开销和减少了kernel和user模式的上下文切换，达到性能的提升。

通过查看源码，消息消费的状态，有2种，一个是成功，一个是失败&稍后重试。在启动broker的过程中，可以观察到上图日志，你会发现RECONSUME_LATER的策略：如果消费失败，那么1S后再次消费，如果失败，那么5S后，再次消费，…直至2H后如果

Clustering模式即同组ConsumerGroup下的每个Consumer消费位置不同,由Broker端存储和控制Offset. rocketMQ和kafka不同1、偏向事务机制；2、不支持Master选举，即不能Slave转Master

RocketMQ是一个分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点，NameServer接受来自Broker群集

最近用SpringBoot集成RocketMQ实现消息实时推送，一直卡在本地启动RocketMQ失败。现在先记录一下，以后看时间解决。当然，如果有好心的朋友，可以提供解决方案。我用的是Apache包，SpringBoot有RocketMQ starter，

近期在研究各种消息队列方案，为了有一个直观的使用体验，我把Kafka，RocketMQ，RabbitMQ各自部署了一遍，并使用了最基本的生产与消费消息功能。在部署过程中也遇到一些问题，特此记录。本文只适用于没有使用过消息队列，还停留在安装部署阶段的新手用户

上世纪90年代末，随着Java EE的出现，特别是Enterprise Java Beans的使用需要复杂的描述符配置和死板复杂的代码实现，增加了广大开发者的学习曲线和开发成本，由此基于简单的XML配置和普通Java对象的Spring技术应运而生，依赖注入

一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师

在消息的传输过程中保存消息的容器；可以把消息看作一个记录，具有特定的格式以及特定的优先级；对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息；消息队列是随内核持续的；使用消息队列就能解决这个

　　1.由于MQ经常处于复杂的分布式系统中，考虑网络波动，服务宕机，程序异常因素，很有可能出现消息发送或者消费失败的问题。因此，消息的重试就是所有MQ中间件必须考虑到的一个关键点。所以，秉承宁可多发消息，也不可丢失消息的原则，大部分MQ都对消息重试提供了很

// producerGroup：一般发送同样消息的Producer，归为同一个Group，应用必须设置，并保证命名唯一。Message msg = new Message("itmayiedu-topic", // topic 主题名

//Create a message instance, specifying topic, tag and message body.Message msg = new Message("TopicTest11" /* Topic *

package com.zn;public static void main(String[] args) throws MQClientException {. DefaultMQProducer producer=new DefaultMQProduc

RocketMQ:　　支持集群，效率高，同时支持上万队列，支持消息持久化，重试机制等等;　　海量消息堆积能力，消息堆积后，写入低延迟。

创建存放压缩包的文件夹,上传压缩包到改文件夹下。按照命令执行就好了。runserver.sh文件修改,将第一行注释更改为。#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数。#删除文件的时间节点，默认凌晨4点

1.安装JDK 1.1 检查当前虚拟机环境有没有JDK rpm -qa|grep java 1.2 卸载 rpm -e --nodeps xxxxxx(自己的openjdk) 1.3 安装JDK 在/usr/local新建一个java文件

启动 Broker 的时候，本地环境建议开启自动创建 Topic，生产环境建议关闭自动化创建 Topic。建议先手工创建 Topic，如果靠程序自动创

producer 在发送消息的时候，会生成一个 "唯一" 的 msgId，broker 会为这个 msgId 创建哈希索引。msgId 由 前缀 + 内容 组成：前缀ip 地址，进程号，classLoader 的 hashcode内容时

它的start方法调用之后，启动了一个netty的客户端bootstrap，每次需要与nameService或者broker进行连接的时候，调用。让线程等待用的是countDownLatch，那么latch之后怎样放行呢？数据的发出是writeAndFlu

本文是根据平时面试以及网上资源进行的整理。希望对小伙伴们面试有帮助。使用消息队列会带来哪些问题？rocketmq不支持队列层面的广播，kafka的consumer group支持组间广播，组内负载均衡。partition：一个topic可以包含一个或多个p

RocketMQ is a distributed messaging and streaming platform with low latency, high performance and reliability, trillion-level ca

5、target目录 通过java -jar的方式运行

日常思维中，顺序大部分情况会和时间关联起来，即时间的先后表示事件的顺序关系。比如事件A发生在下午3点一刻，而事件B发生在下午4点，那么我们认为事件A发生在事件B之前，他们的顺序关系为先A后B。上面的例子之所以成立是因为他们有相同的参考系，即他们的时间是对应

4.Broker如果没有及时的获取发送方本地事务结果的话，会主动查询本地事务结果。

MQ，是一种跨进程的通信机制，用于上下游传递消息。在传统的互联网架构中通常使用MQ来对上下游来做解耦合。不幸的是，Kafka不能满足我们的要求，特别是在低延迟和高可靠性方面。

　　查看日志 tail -f nohup.out . 　　这里不指定端口，服务默认的端口为8080；

公司一个 RocketMQ 集群由4主4从组成，突然其中3台服务器“竟然”在同一时间下线，其监控显示如下：。依次查看三台机器的监控图形，时间戳几乎完美“吻合”，不可思议吧。Java 进程自动退出，一种最常见的问题是由于内存溢出或由于内存泄漏导致进程发送Cr

Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。同步和异步方式均需要Broker返回确认信息，单向发送不需要。代理服务器在RocketMQ系统中负责接