RocketMQ简介

RocketMQ是一款分布式、队列模型的消息中间件。

特点：
1. 能够保证严格的消息顺序
2. 提供丰富的消息拉取模式
3. 高效的订阅者水平扩展能力
4. 实时的消息订阅机制
5. 亿级消息堆积能力
6. 较少的依赖

选用理由：
1. 强调集群无单点，可扩展，任意一点高可用，水平可扩展。
2. 海量消息堆积能力，消息堆积后，写入低延迟。
3. 支持上万个队列
4. 消息失败重试机制
5. 消息可查询
6. 开源社区活跃
7. 成熟度（经过双十一考验）

主题与标签
主题Tpoic：第一级消息类型，书的标题
标签Tags：第二级消息类型，书的目录，可以基于Tag做消息过滤
例如：
主题：
    订单交易
标签：
    订单交易-创建
    订单交易-付款
    订单交易-完成

生产组： 用于消息的发送。
消费组： 用于消息的订阅处理。
生产组和消费组，方便扩缩机器，增减处理能力，集群组的名字，用于标记用途中的一员。每次只会随机的发给每个集群中的一员。

Producer：消息生产者，负责产生消息，一般由业务系统负责产生消息。
Consumer：消息消费者，负责消费消息，一般是后台系统负责异步消费。
Push Consumer：Consumer 的一种，应用通常在 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer 对象立刻回调 Listener 接口方法。
Pull Consumer：Consumer 的一种，应用通常主动调用 Consumer 的拉消息方法从 Broker 拉消息，主动权由应用控制。
Producer Group：一类 Producer 的集合名称，这类 Producer 通常发送一类消息，且发送逻辑一致。
Consumer Group：一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。
Broker：消息中转角色，负责存储消息，转发消息，一般也称为 Server。在 JMS 规范中称为 Provider。

客服端两种消费：
1. 集群消费(负载均衡)
2. 广播消费(非负载均衡)、聊天场景

顺序消费原理：
确保消息发送到用一个队列中，因为队列是按顺序消费的，所以保证了顺序

事务消费原理：
生产端发送消息到MQ(消费端对此消息不可见)，同时执行本地事务，如果本地事务执行成功则改变消息的状态(消费端对此消息可见),如果本地事务不成功，本地回滚，MQ的消息在消费端还是不可见，MQ有定时删除无用数据机制。

异步复制和同步双写是master和slave之间的策略
异步复制：数据写到master就返回
同步双写：数据写到master再写到salve后才返回

异步刷盘和同步刷盘是多个master之间的策略
异步刷盘：数据写到一个master就返回
同步刷盘：数据写到多个master才返回

rocketmq中的所有消息都是持久化的，先写入系统pagecache，然后刷盘，可以保证内存与磁盘都有一份数据，访问时，可以直接从内存读取

 

数据保存在commit log中，同时每条数据的偏移量保存在consume queue和index中，取数据时需要结合consume queue和index来读数据
commit log存储了所有元数据信息，包含消息体，类似于Mysql、oracle的redolog，所以只要有commit log在，consume queue即使数据丢失，任然可以恢复出来。

多master，例如：双主
多master多slave，例如：双主双从

双主双从结构场景下，主从的数据是一致的，如果主节点挂了，从节点继续服务，但从节点始终还是从节点，不会被为主节点，从节点只支持读，当从节点的数据消费完后，就不会接收数据了，负载均衡就失效了

push不支持批处理，只能一次处理一条，但pull支持
pull(主动去拉取，不需监听)比较少用，没有消息重试，需要自己写业务逻辑实现消息重试，大多数都使用push

RocketMQ不保证消息不重复，如果你的业务需要保证严格的不重复消息，需要你自己在业务端去重，但一定不会丢数据，因为有消息重试机制

消息重试、顺序消费、事务消费、并发能力强、消费堆积能力强、经过多次双十一的考验   

RocketMQ默认是有4个队列

v3.2.6，成熟，没有分布式事务，v3.0.8有分布式事务,v3.0.8有事务

RocketMQ集群方式
推荐的几种 Broker 集群部署方式，这里的Slave 不可写，但可读，类似于 Mysql主备方式。
1. 单个 Master
   这种方式风险较大，一旦Broker，重启或者宕机时，会导致整个服务不可用，不建议线上环境使用。
2. 多 Master 模式
   一个集群无 Slave，全是 Master，例如 2 个 Master 或者 3 个 Master

  优点：配置简单，单个Master 宕机或重启维护对应用无影响，在磁盘配置为RAID10 时，即使机器宕机不可恢复情况下，由与 RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高。

  缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到受到影响。

### 先启动 NameServer
### 在机器 A，启动第一个 Master
### 在机器 B，启动第二个 Master

3. 多 Master 多 Slave 模式，异步复制
   每个 Master 配置一个 Slave，有多对Master-Slave， HA采用异步复制方式，主备有短暂消息延迟，毫秒级。
   
   优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master 宕机后，消费者仍然可以从 Slave消费，此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。
   
   缺点： Master 宕机，磁盘损坏情况，会丢失少量消息。
 
### 先启动 NameServer
### 在机器 A，启动第一个 Master
### 在机器 B，启动第二个 Master
### 在机器 C，启动第一个 Slave
### 在机器 D，启动第二个 Slave

4. 多 Master 多 Slave 模式，同步双写
   每个 Master 配置一个 Slave，有多对Master-Slave， HA采用同步双写方式，主备都写成功，向应用返回成功。

   优点：数据与服务都无单点， Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高
 
   缺点：性能比异步复制模式略低，大约低 10%左右，发送单个消息的 RT会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。
 
### 先启动 NameServer
### 在机器 A，启动第一个 Master
### 在机器 B，启动第二个 Master
### 在机器 C，启动第一个 Slave
### 在机器 D，启动第二个 Slave

以上Broker与Slave配对是通过指定相同的brokerName 参数来配对，Master的BrokerId 必须是 0，Slave的BrokerId 必须是大与0的数。另外一个Master下面可以挂载多个Slave，同一 Master下的多个Slave通过指定不同的BrokerId来区分

RocketMQ Console，在tomcat中部署rocketmq-console.war，可以在web页面查询相关信息

broker进程名：brokerStartup
nameserver进程名：namesrvStartup
filter进程名：filtersrvStartup，filter类(java)不能存在中文，不然就读不了文件内容

启动mqnameserver（在bin目录下）命令：nohup sh mqnamesrv &

启动mqbroker命令：
nohup sh mqbroker -c /cloud/alibaba-RocketMQ/conf/2m-noslave/broker-a.properties >/dev/null 2>&1 &
 

数据清理流程：
cd /usr/local/rocketmq/bin
# sh mqshutdown broker
# sh mqshutdown namesrv
# --等待停止
# rm -rf /usr/local/rocketmq/store
# mkdir /usr/local/rocketmq/store
# mkdir /usr/local/rocketmq/store/commitlog
# mkdir /usr/local/rocketmq/store/consumequeue
# mkdir /usr/local/rocketmq/store/index
# 重启 NameServer与BrokerServer

 

#所属集群名字
brokerClusterName=RocketMQ-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-a|broker-b
#0 表示 Master， >0 表示 Slave
brokerId=0
#nameServer地址，分号分割
namesrvAddr=RocketMQ-nameserver1 :9876;RocketMQ-nameserver2:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口
listenPort=10911
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
# commitLog每个文件的大小默认 1G
mapedFileSizeCommitLog=1073741824
# ConsumeQueue每个文件默认存 30W条，根据业务情况调整
mapedFileSizeConsumeQueue=300000
#destroyMapedFileIntervalForcibly=120000
#redeleteHangedFileInterval=120000
#检测物理文件磁盘空间
diskMaxUsedSpaceRatio=88
#存储路径
storePathRootDir=/cloud/alibaba-RocketMQ/store
#commitLog 存储路径
storePathCommitLog=/cloud/alibaba-RocketMQ/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/cloud/alibaba-RocketMQ/store/consumequeue
#消息索引存储路径
storePathIndex=/cloud/alibaba-RocketMQ/store/index
#checkpoint 文件存储路径
storeCheckpoint=/cloud/alibaba-RocketMQ/store/checkpoint
#abort 文件存储路径
abortFile=/cloud/alibaba-RocketMQ/store/abort
#限制的消息大小
maxMessageSize=65536
#flushCommitLogLeastPages=4
#flushConsumeQueueLeastPages=2
#flushCommitLogThoroughInterval=10000
#flushConsumeQueueThoroughInterval=60000
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=ASYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=ASYNC_FLUSH
#checkTransactionMessageEnable=false
#发消息线程池数量
#sendMessageThreadPoolNums=128
#拉消息线程池数量
#pullMessageThreadPoolNums=128

 

以下是我精心整理的文章：

• Java 基础面试题，助你轻松搞定面试官，请点击这里进入
• Java 集合底层原理剖析（List、Set、Map、Queue），请点击这里进入
• 服务注册与发现原理剖析（Eureka、Zookeeper、Nacos），请点击这里进入
• 分布式配置管理的原理剖析（Spring Cloud Config、Apollo、Nacos），请点击这里进入