项目背景
由于产品端有大量的用户行为需要记录日志，考虑到数据存储压力，与前端接口返回速度问题所以将用户数据行为通过消息队列进行解耦。也就是前端应用作为生产者，用户行为处理，比如增加阅读次数，增加行为统计等都通过消费者进行解耦，降低系统所面临的接口压力，保护DB，并有效降低接口超时的风险。
RocketMq搭建与部署
部署结构图如下
image.png
简单说明：两台主机计划搭建集群环境为：两主两从两注册中心的高可用框架
nameserver部署 两台机器拼团与布兜应用服务器构成高可用的注册中心。
broker的部署：两台机器分开部署两个不同的broker主节点，与两个broker的从节点，这样避免某一台机器挂了后死掉两个主，或者两个从节点，组成相对高可用的集群
部署步骤
先修改nameserver启动的jvm参数，因为家境贫寒内存用默认的会造成内存分配失败我暂时就调整jvm参数
打开runserver.sh
vim runserver.sh
找到jvm内存相关配置参数
因为nameserver压力比较小所以无限压榨nameserver内存
JAVA_OPT="${JAVA_OPT} -server -Xms128m -Xmx128m -Xmn64m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m"
另外通过配置文件看到 server端开启的是CMS 垃圾回收器
同理还要修改broker的启动jvm参数，runbroker.sh
打开runbroker.sh
因为broker负责数据读取并且客户端会直连broker压力较大因此将broker的内存配置的稍微大一些
JAVA_OPT="${JAVA_OPT} -server -Xms256m -Xmx256m -Xmn128m"
从启动配置文件来看broker使用的是G1垃圾收集器
基础配置就配置完成了，下面是要配置config/2m-2s-sync目录下的配置，贴一下官方文档的参数配置
这个配置是用来配置broker启动文件的配置参数清单
| Property Name | Default value | Details |
|---|---|---|
| listenPort | 10911 | 监听客户端请求的端口，这个可以不配置随机分配，交给nameserver告诉客户端listen port for client |
| namesrvAddr | null | 当前broker实例要连接的nameserver地址name server address |
| brokerIP1 | InetAddress for network interface | 当前实例的ip，如果是多外网ip可能会上报给nameserver错误，保险起见配置一下Should be configured if having multiple addresses |
| brokerName | null | 当前broker的名字broker name |
| brokerClusterName | DefaultCluster | 当前broker集群的名字this broker belongs to which cluster |
| brokerId | 0 | 当前broker的id，0表示只主节点，broker id, 0 means master, positive integers mean slave |
| storePathCommitLog | $HOME/store/commitlog/ | broker保存commitlog的路径，也就是我们的消息存放路径file path for commit log |
| storePathConsumerQueue | $HOME/store/consumequeue/ | 保存消费者队列的路径，其实是存的消费者组与消息的关联索引file path for consume queue |
| mapedFileSizeCommitLog | 1024 * 1024 * 1024(1G) | commitlogmapped file size for commit log |
| deleteWhen | 04 | 每天几点删除过期的消息When to delete the commitlog which is out of the reserve time |
| fileReserverdTime | 72 | 消息默认保存的时间The number of hours to keep a commitlog before deleting it |
| brokerRole | ASYNC_MASTER | 当前broker角色SYNC_MASTER/ASYNC_MASTER/SLAVE |
| flushDiskType | ASYNC_FLUSH | 消息刷盘机制，如果是同步刷盘会降低消息队列吞吐量{SYNC_FLUSH/ASYNC_FLUSH}. Broker of SYNC_FLUSH mode flushes each message onto disk before acknowledging producer. Broker of ASYNC_FLUSH mode, on the other hand, takes advantage of group-committing, achieving better performance. |
因为我们计划使用两主两从主同步模式启动集群，那么我们需要开始着手修改rocket安装目录下面的配置顺便我们将集中模式梳理在这里
单 master 模式
- 也就是只有一个 master 节点，称不上是集群，一旦这个 master 节点宕机，那么整个服务就不可用，适合个人学习使用。
多 master 模式
- 多个 master 节点组成集群，单个 master 节点宕机或者重启对应用没有影响。
- 优点：所有模式中性能最高
- 缺点：单个 master 节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。
- 注意：使用同步刷盘可以保证消息不丢失，同时 Topic 相对应的 queue 应该分布在集群中各个节点，而不是只在某各节点上，否则，该节点宕机会对订阅该 topic 的应用造成影响。
- conf 目录中的2m模式配置文件
多 master 多 slave 异步复制模式
- 在多 master 模式的基础上，每个 master 节点都有至少一个对应的 slave。
- master 节点可读可写，但是 slave 只能读不能写，类似于 mysql 的主从模式。
- 优点： 在 master 宕机时，消费者可以从 slave 读取消息，消息的实时性不会受影响，性能几乎和多 master 一样。
- 缺点：使用异步复制的同步方式有可能会有消息丢失的问题。
- conf目录中的2m-2s-async目录下的配置文件
多 master 多 slave 同步双写模式
- 同多 master 多 slave 异步复制模式类似，区别在于 master 和 slave 之间的数据同步方式。
- 优点：同步双写的同步模式能保证数据不丢失。
- 缺点：发送单个消息 RT 会略长，性能相比异步复制低10%左右。
- 刷盘策略：同步刷盘和异步刷盘（指的是节点自身数据是同步还是异步存储）
- 同步方式：同步双写和异步复制（指的一组 master 和 slave 之间数据的同步）
- 注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低。
- conf目录中 2m-2s-sync目录下配置文件，布兜项目使用的方式
broker-a-m配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=SYNC_MASTER
flushDiskType=ASYNC_FLUSH
##namesrvAddr 地址
namesrvAddr=172.17.140.1:9876;172.17.139.253:9876
listenPort=10911
##消息存储与commitlog存储目录
storePathRootDir=/usr/local/rocketmq/data/store
storePathCommitLog=/usr/local/rocketmq/data/store/commitlog
#生产环境关闭自动创建topic与group
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
broker-a-s
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
##namesrvAddr 地址
namesrvAddr=172.17.140.1:9876;172.17.139.253:9876
listenPort=11011
##消息存储与commitlog存储目录
storePathRootDir=/usr/local/rocketmq/data/store_s
storePathCommitLog=/usr/local/rocketmq/data/store_s/commitlog
#生产环境关闭自动创建topic与group
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
broker-b-m
brokerClusterName=DefaultCluster
brokerName=broker-b
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=SYNC_MASTER
flushDiskType=ASYNC_FLUSH
##namesrvAddr 地址
namesrvAddr=172.17.140.1:9876;172.17.139.253:9876
listenPort=10911
##消息存储与commitlog存储目录
storePathRootDir=/usr/local/rocketmq/data/store
storePathCommitLog=/usr/local/rocketmq/data/store/commitlog
#生产环境关闭自动创建topic与group
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
broker-b-s
brokerClusterName=DefaultCluster
brokerName=broker-b
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
##namesrvAddr 地址
namesrvAddr=172.17.140.1:9876;172.17.139.253:9876
listenPort=11011
##消息存储与commitlog存储目录
storePathRootDir=/usr/local/rocketmq/data/store_s
storePathCommitLog=/usr/local/rocketmq/data/store_s/commitlog
#生产环境关闭自动创建topic与group
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
修改rocket默认消息保存位置，修改日志保存位置
在rocket安装目录新建 data/store_s 目录用于存放消息与commitlog
image.png
通过sed修改配置文件
进入conf目录，执行 sed -i 's#${user.home}#/usr/local/rocketmq#g' *.xml
这里要注意storePath的不相同行，也就是每台机器的master 与 slave使用的 storePathRootDir storePathCommitLog 要不同，为了方便我一个叫store，另外一个叫store_s
还有就是一定要给主节点与从节点配置监听端口，我一开始没配置，发现一台机器起来主节点后，起不来从节点，我感觉并不是端口占用，应该是在往nameserver注册的时候唯一性的问题，反正正确的道路就是配置好监听端口，这也符合运维习惯因为对外开放端口是要做配置的，不能总是随机监听。
这些准备工作都做好后开始启动服务，我们第一台主机部署有 nameserver1、broker-a-m、broker-b-s.第二台机器部署 nameserver2、broker-b-m、broker-a-s组成高可用集群
启动集群
进入两台机器的rocketmq安装目录的bin目录执行
nohup sh mqnamesrv &
进入第一台机器
启动 brokera 主节点，与broker-b从节点
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-sync/broker-a.properties&
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-sync/broker-b-s.properties&
进入第二台机器
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-sync/broker-b.properties&
nohup sh mqbroker -c /usr/local/rocketmq/conf/2m-2s-sync/broker-a-s.properties&
出现注册成功就可以认为集群搭建完成了
2020-12-14 18:08:03 INFO main - The broker[broker-a, 172.17.139.253:11011] boot success. serializeType=JSON and name server is 172.17.140.1:9876;172.17.139.253:9876
2020-12-14 18:08:06 INFO ReadSocketService - makestop thread ReadSocketService
2020-12-14 18:08:06 INFO ReadSocketService - makestop thread WriteSocketService
2020-12-14 18:08:07 INFO WriteSocketService - makestop thread WriteSocketService
2020-12-14 18:08:07 INFO WriteSocketService - makestop thread ReadSocketService
2020-12-14 18:08:13 INFO BrokerControllerScheduledThread1 - dispatch behind commit log 0 bytes
2020-12-14 18:08:13 INFO BrokerControllerScheduledThread1 - Update slave topic config from master, 172.17.140.1:10911
2020-12-14 18:08:13 INFO BrokerControllerScheduledThread1 - Update slave consumer offset from master, 172.17.140.1:10911
2020-12-14 18:08:13 INFO BrokerControllerScheduledThread1 - Update slave delay offset from master, 172.17.140.1:10911
2020-12-14 18:08:13 INFO BrokerControllerScheduledThread1 - Update slave Subscription Group from master, 172.17.140.1:10911
2020-12-14 18:08:13 INFO BrokerControllerScheduledThread1 - register broker to name server 172.17.139.253:9876 OK
2020-12-14 18:08:13 INFO BrokerControllerScheduledThread1 - register broker to name server 172.17.140.1:9876 OK
2020-12-14 18:08:15 INFO BrokerControllerScheduledThread1 - register broker to name server 172.17.140.1:9876 OK
2020-12-14 18:08:15 INFO BrokerControllerScheduledThread1 - register broker to name server 172.17.139.253:9876 OK
另外备忘几个rocketmq的命令
一、查看消费者情况
sh bin/mqadmin consumerProgress -n localhost:9876
测试环境显示结果
#Group #Count #Version #Type #Model #TPS #Diff Total
guozc-consumer1 0 OFFLINE 0 818
guozc 0 OFFLINE 0 818
behaviorGroup 1 V4_4_0 PUSH CLUSTERING 0 0
guozc2 0 OFFLINE 0 0
在服务端创建topic
sh mqadmin updateTopic -n172.17.140.1:9876 -cDefaultCluster -tbehavior
更多命令查看
sh mqadmin
The most commonly used mqadmin commands are:
updateTopic Update or create topic
deleteTopic Delete topic from broker and NameServer.
updateSubGroup Update or create subscription group
deleteSubGroup Delete subscription group from broker.
updateBrokerConfig Update broker's config
updateTopicPerm Update topic perm
topicRoute Examine topic route info
topicStatus Examine topic Status info
topicClusterList get cluster info for topic
brokerStatus Fetch broker runtime status data
queryMsgById Query Message by Id
queryMsgByKey Query Message by Key
queryMsgByUniqueKey Query Message by Unique key
queryMsgByOffset Query Message by offset
queryMsgByUniqueKey Query Message by Unique key
printMsg Print Message Detail
printMsgByQueue Print Message Detail
sendMsgStatus send msg to broker.
brokerConsumeStats Fetch broker consume stats data
producerConnection Query producer's socket connection and client version
consumerConnection Query consumer's socket connection, client version and subscription
consumerProgress Query consumers's progress, speed
consumerStatus Query consumer's internal data structure
cloneGroupOffset clone offset from other group.
clusterList List all of clusters
topicList Fetch all topic list from name server
updateKvConfig Create or update KV config.
deleteKvConfig Delete KV config.
wipeWritePerm Wipe write perm of broker in all name server
resetOffsetByTime Reset consumer offset by timestamp(without client restart).
updateOrderConf Create or update or delete order conf
cleanExpiredCQ Clean expired ConsumeQueue on broker.
cleanUnusedTopic Clean unused topic on broker.
startMonitoring Start Monitoring
statsAll Topic and Consumer tps stats
allocateMQ Allocate MQ
checkMsgSendRT check message send response time
clusterRT List All clusters Message Send RT
getNamesrvConfig Get configs of name server.
updateNamesrvConfig Update configs of name server.
getBrokerConfig Get broker config by cluster or special broker!
queryCq Query cq command.
创建topic是通过updataTopic命令
sh mqadmin help updateTopic 通过help查看详情
通过topic查询命令查看是否创建成功
sh mqadmin topiclist -n 172.17.140.1:9876
broker-b
BenchmarkTest
OFFSET_MOVED_EVENT
broker-a
behavior
SELF_TEST_TOPIC
DefaultCluster
好的打烊收工，后面再整理一些使用中的坑
