13518219792
RocketMQ网络部署图如下图所示：
公司主营业务：网站设计、成都网站制作、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联公司推出郫都免费做网站回馈大家。
NameServer集群如下：
| NameServer集群 | IP地址 |
|---|---|
| NameServer-1 | 192.168.1.101 |
| NameServer-2 | 192.168.1.102 |
分别启动
nohup sh mqnamesrv &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/namesrv.log众所周知，RocketMQ有多种集群部署方式，它们的配置文件也是分开的，如下：
[root@rocketmq01 conf]# ls -rlt /usr/local/rocketmq/conf
total 32
-rw-r--r-- 1 root root 949 Sep 19 2017 broker.conf
drwxr-xr-x 2 root root 60 Sep 19 2017 2m-noslave
drwxr-xr-x 2 root root 118 Sep 19 2017 2m-2s-sync
drwxr-xr-x 2 root root 118 Sep 19 2017 2m-2s-async
-rw-r--r-- 1 root root 3720 Apr 21 07:56 logback_namesrv.xml
-rw-r--r-- 1 root root 3718 Apr 21 07:56 logback_filtersrv.xml
-rw-r--r-- 1 root root 15146 Apr 21 07:56 logback_broker.xml
-rw-r--r-- 1 root root 3789 Apr 21 07:56 logback_tools.xml说明：
RocketMQ默认提供的配置文件都是最基本的，很多配置都是默认值，在生产环境中我们需要根据实际情况进行修改。样例配置如下：
#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，注意此处不同的配置文件填写的不一样
brokerName=broker-a|broker-b
#0表示Master，>0表示Slave
brokerId=0
#nameServer地址，分号分割
namesrvAddr=192.168.1.101:9876;192.168.1.102: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=/usr/local/alibaba-rocketmq/store
#commitLog 存储路径
storePathCommitLog=/usr/local/alibaba-rocketmq/store/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/alibaba-rocketmq/store/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/alibaba-rocketmq/store/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/alibaba-rocketmq/store/checkpoint
#abort 文件存储路径
abortFile=/usr/local/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=128Broker集群部署有几种不同的方式。这里的Slave不可写，但可读，类似于MySQL的主备方式。
这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用，不建议线上环境使用
一个集群无Slave，全是Master，例如2个Master或者3个Master。
| brokerName | brokerId | brokerRole | IP地址 |
|---|---|---|---|
| broker-a | 0 | ASYNC_MASTER | 192.168.1.101 |
| broker-b | 0 | ASYNC_MASTER | 192.168.1.102 |
优点：
配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢失（异步刷盘丢失少量消息，同步刷盘一条不丢）。性能最高。缺点：
单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
启动步骤：
第一步：先启动NameServer集群
第二步：在192.168.1.101，启动第一个Master
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log第三步：在192.168.1.102，启动第二个Master
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟，毫秒级。
| brokerName | brokerId | brokerRole | IP地址 |
|---|---|---|---|
| broker-a | 0 | ASYNC_MASTER | 192.168.1.101 |
| broker-a | 1 | SLAVE | 192.168.1.102 |
| broker-b | 0 | ASYNC_MASTER | 192.168.1.103 |
| broker-b | 1 | SLAVE | 192.168.1.104 |
优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master 宕机后，消费者仍然可以从Slave消费，此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。
缺点：Master宕机，磁盘损坏情况，会丢失少量消息。
启动步骤
第一步：先启动NameServer集群
第二步：在192.168.1.101，启动第一个Master
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log第三步：在192.168.1.102，启动第一个Slave
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log第四步：在192.168.1.103，启动第二个Master
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log第五步：在机器 192.168.1.104，启动第二个Slave
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &| 每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，主备都写成功，向应用才返回成功。 brokerName | brokerId | brokerRole | IP地址 |
|---|---|---|---|
| broker-a | 0 | SYNC_MASTER | 192.168.1.101 |
| broker-a | 1 | SLAVE | 192.168.1.102 |
| broker-b | 0 | SYNC_MASTER | 192.168.1.103 |
| broker-b | 1 | SLAVE | 192.168.1.104 |
优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高。
缺点：性能比异步复制模式略低，大约低10%左右，发送单个消息的RT会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。
启动步骤：
第一步：先启动NameServer集群
第二步：在192.168.1.101，启动第一个Master
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log第三步：在192.168.1.102，启动第一个Slave
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log第四步：在192.168.1.103，启动第二个Master
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log第五步：在192.168.1.104，启动第二个Slave
nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 &
tail -f -n 500 $ROCKETMQ_HOME/logs/rocketmqlogs/broker.log注意事项：以上Broker与Slave配对是通过指定相同的brokerName参数来配对，Master的 BrokerId必须是0，Slave的BrokerId必须是大于0的数。另外一个Master下面可以挂载多个Slave，同一Master下的多个Slave 通过指定不同的BrokerId来区分。
1、异步复制和同步双写总结
2、集群方式对比
| 集群方式 | 运维特点 | 消息可靠性(master宕机情况) | 服务可用性(master宕机情况) | 其他特点 | 备注 |
|---|---|---|---|---|---|
| 单Master | 结构简单，扩容方便，机器要求低 | 同步刷盘消息一条都不会丢 | 整体可用，未被消费的消息无法取得，影响实时性 | 性能最高 | |
| 多Master | 异步有毫秒级丢失，同步双写不丢失 | 差评，主备不能自动切换，且备机只能读不能写，会造成服务整体不可写 | 不考虑，除非自己提供主从切换的方案 | ||
| Master-Slave(异步复制) | 结构复杂，扩容方便 | 故障时会丢失消息 | 整体可用，实时性影响毫秒级别 | ||
| 该组服务只能读不能写 | 性能很高 | 适合消息可靠性中等，实时性中等的要求 | |||
| Master-Slave(同步双写) | 结构复杂，扩容方便 | 不丢消息 | 整体可用，不影响实时性，该组服务只能读不能写 | 性能比异步低10%，所以实时性也并不比异步方式太高 | 适合消息可靠性略高，实时性中等、性能要求不高的需求 |
RocketMQ高可用演练场景
| 项目 | 发送消息 | 发送消息过程中 | 接收消费消息 |
|---|---|---|---|
| 停用一个namesrv | 不影响通信 | 不影响通信 | 不影响通信 |
| 停用全部namesrv | 影响通信 | 不影响通信 | 影响通信，启动任意的namesrv可恢复 |
| 停用单个master broker | 不影响通信 | 不影响通信 | 不影响通信 |
| 停用全部master broker | 影响通信 | 影响通信，无法恢复 | 影响通信 |
| 停用一个slave broker | 不影响通信 | 不影响通信 | 不影响通信 |
| 停用全部slave broker | 不影响通信 | 影响通信，数秒恢复 | 不影响通信，数秒恢复 |
下面的是我的公众号二维码，欢迎关注。文章转载请注明出处www.leexide.com
