@[toc]
源码包结构
进入rocket的github官方地址：https://github.com/apache/rocketmq可以看到当前最新的 releases 版本是4.9.4，下载最新的源码包到本地。
执行以下命令解压源码包，并通过maven打包构建。
源码包模块结构说明：rocketmq-broker：主要的业务逻辑，消息收发，主从同步，pagecacherocketmq-client：客户端接口，比如生产者和消费者。rocketmq-common：公用数据结构等等。rocketmq-distribution：编译模块，编译输出等。rocketmq-example：示例，比如生产者和消费者。rocketmq-fliter：进行Broker过滤的不感兴趣的消息传输，减小带宽压力。rocketmq-logappender、rocketmq-logging：日志相关。rocketmq-namesrv Namesrv：服务，用于服务协调。rocketmq-openmessaging：对外提供服务。rocketmq-remoting：远程调用接口，封装Netty底层通信。rocketmq-srvutil：提供一些公用的工具方法，比如解析命令行参数。rocketmq-store：消息存储核心包。rocketmq-test：提供一些测试代码包。rocketmq-tools：管理工具，比如有名的mqadmin工具。
集群架构
双主双从部署图RocketMQ为我们提供了丰富的集群架构模型，包括单点模式、主从模式、双主模式以及生产上使用最多的双主双从模式（或者说多主多从模式）。集群配置方案案例：2m-2s-async：双主双从异步方式。2m-2s-sync：双主双从同步方式。2m-noslave：双主模式。
以下是Broker 集群部署方式，这里的Slave 不可写，但可读，类似于 Mysql 主备方式。
单个 Master
这种方式风险较大，一旦Broker 重启或者宕机时，会导致整个服务不可用，不建议线上环境使用。启动方式：
验证Name Server 是否启动成功
$ tail -f ~/logs/rocketmqlogs/namesrv.logThe Name Server boot success...
2. 再启动 Broker ```shell ### 启动Broker $ nohup sh bin/mqbroker -n localhost:9876 & ### 验证Name Server 是否启动成功，例如Broker的IP为：192.168.1.2，且名称为broker-a $ tail -f ~/logs/rocketmqlogs/Broker.log The broker[broker-a, 192.169.1.2:10911] boot success...多 Master 模式
一个集群无 Slave，全是 Master，例如 2 个 Master 或者 3 个 Master。优点：配置简单，单个Master 宕机或重启维护对应用无影响，在磁盘配置为 RAID10(磁盘阵列，用于数据保护) 时，即使机器宕机不可恢复情况下，由于 RAID10 磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢）。性能最高。缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到受到影响。启动方式：
NameServer需要先于Broker启动，且如果在生产环境使用，为了保证高可用，建议一般规模的集群启动3个NameServer，各节点的启动命令相同，如下：
### 首先启动Name Server $ nohup sh mqnamesrv & ### 验证Name Server 是否启动成功 $ tail -f ~/logs/rocketmqlogs/namesrv.log The Name Server boot success...在机器B，启动第二个Master，例如NameServer的IP为：192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties &
...
以上启动命令是在单个NameServer情况下使用的。对于多个NameServer的集群，Broker启动命令中-n后面的地址列表用分号隔开即可，例如 192.168.1.1:9876;192.161.2:9876。 ### 多 Master 多 Slave 模式，异步复制 每个 Master 配置一个 Slave，有多对Master-Slave，HA 采用异步复制方式，主备有短暂消息延迟，毫秒级。 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为 Master 宕机后，消费者仍然可以从 Slave 消费，此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。 缺点：Master 宕机，磁盘损坏情况，会丢失少量消息。 `启动命令`： 1. 启动NameServer ```shell ### 首先启动Name Server $ nohup sh mqnamesrv & ### 验证Name Server 是否启动成功 $ tail -f ~/logs/rocketmqlogs/namesrv.log The Name Server boot success...在机器B，启动第二个Master，例如NameServer的IP为：192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties &
在机器C，启动第一个Slave，例如NameServer的IP为：192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties &
在机器D，启动第二个Slave，例如NameServer的IP为：192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties &
### 多 Master 多 Slave 模式，同步双写 每个 Master 配置一个 Slave，有多对Master-Slave，HA 采用同步双写方式，主备都写成功，向应用返回成功。 优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高 缺点：性能比异步复制模式略低，大约低 10%左右，发送单个消息的 RT 会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。 `启动方式`： 1. 启动NameServer ```shell ### 首先启动Name Server $ nohup sh mqnamesrv & ### 验证Name Server 是否启动成功 $ tail -f ~/logs/rocketmqlogs/namesrv.log The Name Server boot success...在机器B，启动第二个Master，例如NameServer的IP为：192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties &
在机器C，启动第一个Slave，例如NameServer的IP为：192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties &
在机器D，启动第二个Slave，例如NameServer的IP为：192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties &
以上 Broker 与 Slave 配对是通过指定相同的brokerName 参数来配对，Master 的 BrokerId 必须是 0，Slave 的BrokerId 必须是大与 0 的数。另外一个 Master 下面可以挂载多个 Slave，同一 Master 下的多个 Slave通过指定不同的 BrokerId 来区分。 > 本文内容到此结束了， > 如有收获欢迎点赞