RocketMQ原理及常见问题

本地安装教程

RocketMQ安装教程
1、RocketMQ下载：地址
2、设置环境变量

ROCKETMQ_HOME=D:\Software\rocketMq
NAMESRV_ADDR=localhost:9876

3、启动服务

1、进入已安装的RocketMQ的bin目录，cmd打开命令窗口
2、启动nameServer，命令：start mqnamesrv.cmd 
3、启动broker，命令：start mqbroker.cmd -n 0.0.0.0:9876 -c D:\Software\rocketMq\conf\broker.conf
4、创建topic，命令：mqadmin.cmd updateTopic -b localhost:10911 -t TopicTest

4、RocketMQ图形界面安装，安装教程
5、生产者消费者代码示例

RocketMQ简介

RocketMQ是一款分布式消息中间件，最初是由阿里巴巴消息中间件团队研发并大规模应用于生产系统，满足线上海量消息堆积的需求， 在2016年底捐赠给Apache开源基金会成为孵化项目，经过不到一年时间正式成为了Apache顶级项目；早期阿里曾经基于ActiveMQ研发消息系统， 随着业务消息的规模增大，瓶颈逐渐显现，后来也考虑过Kafka，但因为在低延迟和高可靠性方面没有选择，最后才自主研发了RocketMQ， 各方面的性能都比目前已有的消息队列要好，RocketMQ和Kafka在概念和原理上都非常相似，所以也经常被拿来对比；RocketMQ默认采用长轮询的拉模式， 单机支持千万级别的消息堆积，可以非常好的应用在海量消息系统中。

1、RocketMQ的优点

消息异步、系统解耦、流量削峰
RocketMQ具体优点及与其他MQ对比，详情见链接

2、整体结构

NameServer：是一个很简单的 Topic 路由注册中心，支持 Broker 的动态注册和发现，保存 Topic 和 Borker 之间的关系。通常也是集群部署，但是各 NameServer 之间不会互相通信，相互之间独立，其他角色同时向多个NameServer机器上报状态信息，从而达到热备份的目的。 NameServer本身是无状态的，也就是说NameServer中的Broker、Topic等状态信息不会持久存储，都是由各个角色定时上报并 存储到内存中的(NameServer支持配置参数的持久化，一般用不到)。
Broker：主要负责消息的存储、查询消费，支持主从部署，一个 Master 可以对应多个 Slave，Master 支持读写，Slave 只支持读。Broker 会向集群中的每一台 NameServer 注册自己的路由信息。
Producer：就是消息生产者，可以集群部署。它会先和 NameServer 集群中的随机一台建立长连接，得知当前要发送的 Topic 存在哪台 Broker Master上，然后再与其建立长连接，支持多种负载平衡模式发送消息。
Consumer：消息消费者，也可以集群部署。它也会先和 NameServer 集群中的随机一台建立长连接，得知当前要消息的 Topic 存在哪台 Broker Master、Slave上，然后它们建立长连接，支持集群消费和广播消费消息。

我再用一段话来概括它们之间的交互：

先启动 NameServer 集群，各 NameServer 之间无任何数据交互，Broker 启动之后会向所有 NameServer 定期（每 30s）发送心跳包，包括：IP、Port、TopicInfo，NameServer 会定期扫描 Broker 存活列表，如果超过 120s 没有心跳则移除此 Broker 相关信息，代表下线。这样每个 NameServer 就知道集群所有 Broker 的相关信息。
此时 Producer 上线从 NameServer 就可以得知它要发送的某 Topic 消息在哪个 Broker 上，和对应的 Broker （Master 角色的）建立长连接，发送消息。
Consumer 上线也可以从 NameServer 得知它所要接收的 Topic 是哪个 Broker ，和对应的 Master、Slave 建立连接，接收消息。

3、消息模型

rocketmq采用的是发布-订阅的模式，不需要每个消费者维护自己的消息队列，生产者将消息发送到topic,消费者订阅此topic 读取消息。
Topic：主题，可以看做消息的归类，它是消息的第一级类型。
Tag：标签，可以看作子主题，它是消息的第二级类型
Group：RocketMQ中，订阅者的概念是通过消费组（Consumer Group）来体现的。每个消费组都消费主题中一份完整的消息，不同消费组之间消费进度彼此不受影响，也就是说，一条消息被Consumer Group1消费过，也会再给Consumer Group2消费。
Message Queue：消息队列，一个 Topic 下可以设置多个消息队列
Offset：在Topic的消费过程中，由于消息需要被不同的组进行多次消费，所以消费完的消息并不会立即被删除，这就需要RocketMQ为每个消费组在每个队列上维护一个消费位置（Consumer Offset），这个位置之前的消息都被消费过，之后的消息都没有被消费过，每成功消费一条消息，消费位置就加一。也可以这么说，Queue 是一个长度无限的数组，Offset 就是下标。

RocketMQ的消息模型中，这些就是比较关键的概念了。画张图总结一下：

4、消息的消费模式

消息消费模式有两种：Clustering（集群消费）和Broadcasting（广播消费）
集群消费：默认模式，这种模式下一个消费者组共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。
广播消费：消息会发给消费者组中的每一个消费者进行消费。

相关问题

1、分布式事务的数据一致性

流程说明如下：
注册系统向消息队列RocketMQ发送半事务消息。
1.1. 半事务消息发送成功，进入2。
1.2. 半事务消息发送失败，注册系统不进行注册，流程结束。（最终注册系统与邮件通知系统数据一致）

注册系统开始注册。
2.1. 注册成功，进入3.1。
2.2. 注册失败，进入3.2。

注册系统向消息队列RocketMQ发送半消息状态。
3.1. 提交半事务消息，产生注册成功消息，进入4。
3.2. 回滚半事务消息，未产生注册成功消息，流程结束。
说明 最终注册系统与邮件通知系统数据一致。

邮件通知系统接收消息队列RocketMQ的注册成功消息。
邮件通知系统发送注册成功邮件。（最终注册系统与邮件通知系统数据一致）
关于分布式事务消息的更多详细内容，请参见事务消息。

2、RocketMQ重试机制(ACK确认机制)

直接上链接吧：链接