RocketMq使用经验总结
RocketMq简介
基本概念
Produce
消息生产者，负责产生消息，一般由业务系统负责产生消息。
Consumer
消息消费者，负责消费消息，一般是后台系统负责异步消费。
Push Consumer
Consumer的一种，应用通常向Consumer对象注册一个Listener接口，一旦收到消息，Consumer对象立刻回调Listener接口方法。
Pull Consumer
Consumer的一种，应用通常主动调用Consumer的拉消息方法从Broker拉消息，主动权由应用控制。
ProducerGroup
一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致。
Consumer Group
一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致。
Broker
消息中转角色，负责存储消息，转发消息，一般也称为Server
NameService
负责路由，管理。
广播消费
一条消息被多个Consumer消费，即使这些Consumer属于同一个Consumer Group，消息也会被Consumer Group中的每个Consumer都消费一次，广播消费中的Consumer Group概念可以认为在消息划分方面无意义。
集群消费
一个Consumer Group中的Consumer实例平均分摊消费消息。例如某个Topic有9条消息，其中一个Consumer Group有3个实例（可能是3个进程，或者3台机器），那么每个实例只消费其中的3条消息。
消费方式如图：
部署架构设计如图：
-
Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
-
Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
-
Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
-
Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
Producer、Consumer、topic关系如图：
图中红字出现的原因：
在不同的 JVM 中启动了多个 Consumer，并且给相同的 Consumer ID 配置了不同的 Topic，
或者是相同的 Topic 但 Tag 不同，最终导致订阅关系不一致，消息不符合预期
生产问题总结
- 不同jvm同一topic下，tag的订阅不一致，导致消息状态不一致，产生消费堵塞；
- 同一个consumer分组下面的consumer的topic订阅不一致，导致消息状态不一致，产生消费堵塞；
- 某一个consumer下线之后，下线状态没有同步整个集群；
- 某个broker下没有消费者注册；
- 网络不稳定或是消费者consumer重启，消息重复消费
生产经验总结
生产中出现的问题最多的就是：消息状态不一致，导致消息挤压，比如前面提到的a、b两个问题。解决方案：“在不同的 JVM 中启动了多个 Consumer，并且给相同的 Consumer ID 配置了不同的 Topic，或者是相同的 Topic 但 Tag 不同，最终导致订阅关系不一致，消息不符合预期”；
问题3、4其实从解决方案上来说都是属于同一类问题。解决方案：查看相应消息对应的consumer分组下面的topic上是否有注册上应该注册的消费者。
如图：
如果有问题只能选择性的重启某个或是全部broken或者所有的NameService。
问题5的解决方案：业务上做去重处理，可以根据业务上的唯一订单号，也可以根据rocketMq的messageId来做限制
安全与高可用
刷盘策略
RocketMQ的所有消息都是持久化的，先写入系统PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，访问时，直接从内存读取。可分类为同步刷盘、异步刷盘，如图：
同步双写/异步复制
异步复制的实现思路非常简单，Slave启动一个线程，不断从Master拉取Commit Log中的数据，然后在异步build出Consume Queue数据结构。
同步双写主备都写成功的时候才向应用返回成功。整个实现过程基本同Mysql主从同步类似。
NameService
nameservice主要是起到路由功能，注册和发现服务。NameService是无状态的，可以部署多套，可保证高可用
Broker部署结构
###单个Master
这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用，不建议线上环境使用
多Master模式
一个集群无Slave，全是Master，例如2个Master或者3个Master。
优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高。
缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到受到影响。
多Master多Slave模式，异步复制
每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟，毫秒级。
优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master宕机后，消费者仍然可以从Slave消费，此过程对应用透明。不需要人工干预。性能同多Master模式几乎一样。
缺点：Master宕机，磁盘损坏情况，会丢失少量消息。
多Master多Slave模式，同步双写
每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，主备都写成功，向应用返回成功。
优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高
缺点：性能比异步复制模式略低，大约低10%左右，发送单个消息的RT会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。
Broker重启对客户端的影响
Broker重启可能会导致正在发往这台机器的的消息发送失败，RocketMQ提供了一种优雅关闭Broker的方法，通过执行以下命令会清除Broker的写权限，过40s后，所有客户端都会更新Broker路由信息，此时再关闭Broker就不会发生发送消息失败的情况，因为所有消息都发往了其他Broker。
sh mqadmin wipeWritePerm-b brokerName -n namesrvAddr
运维步骤及常见问题:
线上环境架构
一般生产环境采用多Master多Slave模式，异步复制方式，当前线上Master部署部署在一台机，Slave部署在另一台机，如图：
关键位置配置 –- broker-a.properties
brokerClusterName=rocketmq-sxzy #所属集群名称
brokerName=broker-a #broker名字，注意此处不同的配置文件填写的不一样
#nameServer地址，分号分割
namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876;rocketmq-nameserver3:9876;rocketmq-nameserver4:9876
brokerId=0 #0表示Master，>0 表示 Slave
deleteWhen=04 #删除文件时间点，默认凌晨 4点
fileReservedTime=120 #文件保留时间，默认 48 小时
defaultTopicQueueNums=4 #在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
autoCreateTopicEnable=true #是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true #是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
#Broker 对外服务的监听端口
listenPort=10911
mapedFileSizeConsumeQueue=300000 #ConsumeQueue每个文件默认存30W条，根据业务情况调整
brokerRole=ASYNC_MASTER # 异步复制Master
flushDiskType=ASYNC_FLUSH #异步刷盘
重启脚本
#!/bin/sh
#kill 进程
echo "正在关闭 mq-server"
/data/cloud2/RocketMq/bin/mqshutdown namesrv
sleep 1
ps -ef |grep mqnamesrv |grep -v grep |awk '{print $2}' |xargs kill -9
echo "正在关闭 mq-broker"=
/data/cloud2/RocketMq/bin/mqshutdown broker
sleep 1
ps -ef |grep broker|grep -v grep |awk '{print $2}' |xargs kill -9
#启动进程
echo "正在启动mq-server"
nohup sh /usr/cloud2/RocketMq/bin/mqnamesrv >/usr/cloud2/RocketMq/logs/mqnamesrv.log 2>&1 &
sleep 1
echo "正在启动broker-a"
nohup sh /usr/cloud2/RocketMq/bin/mqbroker -c /usr/cloud2/RocketMq/conf/2m-2s-sync/broker-a.properties > /usr/cloud2/RocketMq/logs/broker-a.log 2>&1 &
sleep 1
echo "正在启动broker-b"
nohup sh /usr/cloud2/RocketMq/bin/mqbroker -c /usr/cloud2/RocketMq/conf/2m-2s-sync/broker-b.properties > /usr/cloud2/RocketMq/logs/broker-b.log 2>&1 &
sleep 1
jps
echo "mq服务启动完毕，请检查NamesrvStartup和BrokerStartup是否存在“
MQ控制台
RocketMQDemo
-
使用maven编译成war包，或从网上下载别人打好的包
-
修改config.properties
rocketmq.namesrv.addr=mqnameserver1:9876;mqnameserver2:9876
-
启动tomcat,浏览器里输入 http://ip:端口/rocketmq-console 访问
rocketmq-console-ng
-
使用maven编译成war包，或从网上下载别人打好的包(网上大多jar)
-
修改application.properties
rocketmq.config.namesrvAddr=mqnameserver1:9876;mqnameserver2:9876
-
启动tomcat,浏览器里输入 http://ip:端口/rocketmq-console-ng 访问
或使用jar启动java -jar rocketmq-console-ng-1.0.0.jar --server.port=12581 --rocketmq.config.namesrvAddr=mqnameserver1:9876;mqnameserver2:9876
创建生产者
创建消费者
异常问题处理：
-
进程不存在:：使用ps –ef |grep mq 或使用jps命令查看 Mqname 和
brokerName组进程是否存在 -
磁盘空间满：如果磁盘满，根据下面路径删除最不重要的文件
#存储路径
storePathRootDir=/data/cloud2/RocketMq/data/store_a
#commitLog 存储路径
storePathCommitLog=/data/cloud2/RocketMq/data/store_a/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/data/cloud2/RocketMq/data/store_a/consumequeue
#消息索引存储路径
storePathIndex=/data/cloud2/RocketMq/data/store_a/index
#checkpoint 文件存储路径
storeCheckpoint=/data/cloud2/RocketMq/data/store_a/checkpoint
#abort 文件存储路径
abortFile=/data/cloud2/RocketMq/data/store_a/abort -
消息不消费：通过控制台检查订阅关系是否一致，和查看消费者终端信息
-
生产者故障：检查程序topic配置，实在检查不出问题直接执行上面重启脚本
现存未解决问题
各种高可用方案没有具体验证过。