本文主要介绍 RocketMQ 的安装部署，文中所使用到的软件版本：RocketMQ 5.1.3、CentOS7.9.2009。
1、RocketMQ 部署模型
1.1、部署模型说明
Apache RocketMQ 部署架构上主要分为四部分:
A、生产者 Producer
发布消息的角色。Producer 通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。
B、消费者 Consumer
消息消费的角色。
C、名字服务器 NameServer
NameServer是一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。
主要包括两个功能：
1、Broker 管理：NameServer 接受 Broker 集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查 Broker 是否还存活；
2、路由信息管理：每个 NameServer 将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer 和 Consumer 通过 NameServer 就可以知道整个 Broker 集群的路由信息，从而进行消息的投递和消费。
NameServer 通常会有多个实例部署，各实例间相互不进行信息通讯。Broker 是向每一台 NameServer 注册自己的路由信息，所以每一个- NameServer 实例上面都保存一份完整的路由信息。当某个NameServer 因某种原因下线了，客户端仍然可以向其它 NameServer 获取路由信息。
D、代理服务器 Broker
Broker 主要负责消息的存储、投递和查询以及服务高可用保证。NameServer 几乎无状态节点，因此可集群部署，节点之间无任何信息同步。Broker 部署相对复杂。
在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个 Master 可以对应多个 Slave，但是一个 Slave 只能对应一个 Master。Master 与 Slave 的对应关系通过指定相同的 BrokerName，不同的BrokerId 来定义，BrokerId 为 0 表示 Master，非 0 表示 Slave。Master 也可以部署多个。
1.2、部署模型小结
A、每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
B、Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
C、Consumer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave 发送心跳。Consumer 既可以从 Master 订阅消息，也可以从 Slave 订阅消息。
1.3、proxy 组件
5.0 版本新增了 proxy 组件，部署时根据实际诉求可以分为 Local 模式和 Cluster 模式，一般情况下如果没有特殊需求，或者遵循从早期版本平滑升级的思路，可以选用
在 Local 模式下，Broker 和 Proxy 是同进程部署，只是在原有 Broker 的配置基础上新增 Proxy 的简易配置就可以运行。
在 Cluster 模式下，Broker 和 Proxy 分别部署，即在原有的集群基础上，额外再部署 Proxy 即可。
2、RocketMQ 部署2.1、下载部署包
从官网(https://rocketmq.apache.org/zh/download)下载部署包并解压：
unzip rocketmq-all-5.1.3-bin-release.zip
2.2、集群规划
假设在 10.49.196.30、10.49.196.31、10.49.196.32、10.49.196.33四台机器上按各种模式安装RocketMQ。
2.3、Local 模式部署
由于 Local 模式下 Proxy 和 Broker 是同进程部署，Proxy 本身无状态，因此主要的集群配置仍然以 Broker 为基础进行即可。
2.3.1、单组节点单副本模式
A、启动NameServer
nohup bin/mqnamesrv &tail -f ~/logs/rocketmqlogs/namesrv.log #查看日志B、启动 Broker + Proxy
nohup bin/mqbroker -n localhost:9876 --enable-proxy &tail -f ~/logs/rocketmqlogs/broker_default.log #查看日志
注意：这种方式风险较大，因为 Broker 只有一个节点，一旦 Broker 重启或者宕机时，会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。
2.3.2、多组节点（集群）单副本模式
一个集群内全部部署 Master 角色，不部署 Slave 副本，例如 2 个 Master 或者 3 个 Master，这种模式的优缺点如下：
优点：配置简单，单个 Master 宕机或重启维护对应用无影响，在磁盘配置为 RAID10 时，即使机器宕机不可恢复情况下，由于 RAID10 磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
A、启动NameServer
在 10.49.196.30、10.49.196.31、10.49.196.32 三台机器上分别启动 NameServer。
nohup bin/mqnamesrv &
B、启动 Broker + Proxy 集群
在10.49.196.30 上启动第一个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties --enable-proxy &
在10.49.196.31 上启动第二个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties --enable-proxy &
2.3.3、多节点（集群）多副本模式-异步复制
每个 Master 配置一个 Slave，有多组 Master-Slave，HA 采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：
优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时 Master 宕机后，消费者仍然可以从 Slave 消费，而且此过程对应用透明，不需要人工干预，性能同多 Master 模式几乎一样；
缺点：Master 宕机，磁盘损坏情况下会丢失少量消息。
A、启动NameServer
在 10.49.196.30、10.49.196.31、10.49.196.32 三台机器上分别启动 NameServer。
nohup bin/mqnamesrv &
B、启动 Broker + Proxy 集群
在10.49.196.30 上启动第一个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties --enable-proxy &
在10.49.196.31 上启动第二个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties --enable-proxy &
在10.49.196.32 上启动第一个 Slave：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties --enable-proxy &
在10.49.196.33 上启动第二个 Slave：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties --enable-proxy &
2.3.4、多节点（集群）多副本模式-同步双写
每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：
优点：数据与服务都无单点故障，Master 宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；
缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的 RT 会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。
A、启动NameServer
在 10.49.196.30、10.49.196.31、10.49.196.32 三台机器上分别启动 NameServer。
nohup bin/mqnamesrv &
B、启动 Broker + Proxy 集群
在10.49.196.30 上启动第一个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties --enable-proxy &
在10.49.196.31 上启动第二个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties --enable-proxy &
在10.49.196.32 上启动第一个 Slave：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties --enable-proxy &
在10.49.196.33 上启动第二个 Slave：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties --enable-proxy &
注：以上 Broker 与 Slave 配对是通过指定相同的 BrokerName 参数来配对，Master 的 BrokerId 必须是 0，Slave 的 BrokerId 必须是大于 0 的数。另外一个 Master 下面可以挂载多个 Slave，同一 Master 下的多个 Slave 通过指定不同的 BrokerId 来区分。
2.4、Cluster模式部署
在 Cluster 模式下，Broker 与 Proxy 分别部署(Broker 启动时不要添加 –enable-proxy 参数)，可以在 NameServer和 Broker 都启动完成之后再部署 Proxy。
在 Cluster 模式下，一个 Proxy 集群和 Broker 集群为一一对应的关系，可以在 Proxy 的配置文件 rmq-proxy.json 中使用 rocketMQClusterName 进行配置。
这里以 Broker 的“多节点（集群）多副本模式-同步双写” 模式为例来部署 RocketMQ。
2.4.1、启动 NameServer
在 10.49.196.30、10.49.196.31、10.49.196.32 三台机器上分别启动 NameServer。
nohup bin/mqnamesrv &
2.4.2、启动Broker
在10.49.196.30 上启动第一个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties &
在10.49.196.31 上启动第二个 Master：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties &
在10.49.196.32 上启动第一个 Slave：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties &
在10.49.196.33 上启动第二个 Slave：
nohup bin/mqbroker -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties &
2.4.3、启动Proxy
在 10.49.196.30、10.49.196.31、10.49.196.32 三台机器上分别启动 Proxy。
nohup bin/mqproxy -n '10.49.196.30:9876;10.49.196.31:9876;10.49.196.32:9876' &
3、Broker 参数说明
| 参数名 | 默认值 | 说明 |
|---|---|---|
| listenPort | 10911 | 接受客户端连接的监听端口 |
| namesrvAddr | null | nameServer 地址 |
| brokerIP1 | 网卡的 InetAddress | 当前 broker 监听的 IP |
| brokerIP2 | 跟 brokerIP1 一样 | 存在主从 broker 时，如果在 broker 主节点上配置了 brokerIP2 属性，broker 从节点会连接主节点配置的 brokerIP2 进行同步 |
| brokerName | null | broker 的名称 |
| brokerClusterName | DefaultCluster | 本 broker 所属的 Cluser 名称 |
| brokerId | 0 | broker id, 0 表示 master, 其他的正整数表示 slave |
| storePathCommitLog | $HOME/store/commitlog/ | 存储 commit log 的路径 |
| storePathConsumerQueue | $HOME/store/consumequeue/ | 存储 consume queue 的路径 |
| mapedFileSizeCommitLog | 1024*1024*1024(1G) | commit log 的映射文件大小 |
| deleteWhen | 04 | 在每天的什么时间删除已经超过文件保留时间的 commit log |
| fileReservedTime | 72 | 以小时计算的文件保留时间 |
| brokerRole | ASYNC_MASTER | SYNC_MASTER/ASYNC_MASTER/SLAVE |
| flushDiskType | ASYNC_FLUSH | SYNC_FLUSH/ASYNC_FLUSH SYNC_FLUSH 模式下的 broker 保证在收到确认生产者之前将消息刷盘。ASYNC_FLUSH 模式下的 broker 则利用刷盘一组消息的模式，可以取得更好的性能。 |
4、RocketMQ Dashboard 部署
RocketMQ Dashboard 是 RocketMQ 的管控利器，为用户提供客户端和应用程序的各种事件、性能的统计信息，支持以可视化工具代替 Topic 配置、Broker 管理等命令行操作。
4.1、下载源码并编译
源码地址：apache/rocketmq-dashboard，下载并解压，切换至源码目录rocketmq-dashboard-master：
mvn clean package -Dmaven.test.skip=true4.2、运行
RocketMQ Dashboard 默认的端口为 8080，与 Proxy 端口冲突，可以修改其运行端口：
java -Dserver.port=18080 -jar target/rocketmq-dashboard-1.0.1-SNAPSHOT.jar
效果如下：
参考：https://rocketmq.apache.org/zh/docs/deploymentOperations/01deploy