rocketmq使用nameserver 与 broker NameServer: NameServer 是 RocketMQ 的名称服务器，负责管理消息队列和消费者组。 Broker：Broker 是 RocketMQ 的消息代理服务器，负责接收、处理和存储消息。 Proxy: Proxy 是 RocketMQ 的代理服务器，用于扩展消息代理服务器的性能和容量。Proxy 可以将消息路由 到多个 Broker 上，以实现负载均衡和容错。Proxy 还提供了一些接口，如队列管理、消费者管理、配置管理 等，供客户端使用。 ======================================= 集群启动 推荐3 个nameserver 1. nameserver 可以在不同的机器上直接启动 无需配置管理， broker会向nameserver同步 topic等信息 2. 启动broker /Users/zjh/rocketmqstudy/rocketmq-all-5.4.0-bin-release/conf 下会有几个配置文件夹 2m-2s-async 代表2个master broker 与2个从broker 只同步master broker 的消息/写入只同步master broker后应答 异步同步从broker 2m-2s-sync 代表2个master broker 与2个从broker 写入消息需要master 跟 对应的从 broker 消息一起写入完毕后才应答 2m-noslave 设置磁盘阵列为raid10只使用两个maeterbroker 同步刷屏不会丢失消息， 异步刷盘丢失少量消息 *******nohup + 下面命令 + & //后台运行 可加可不加 --enable-proxy 在当前进程中一起启动代理 ******* sh mqbroker -n "localhost:9876;另一个nameserver的地址与端口;第三个nameserver的地址与端口" -c ../conf/2m-noslave/broker-a.properties --enable-proxy ****** 启动 broker时2m-noslave 文件夹下会有多个properties，每个broker 启动只能用一个 broker-a.properties 后 需要用b.properties *********** 不同的properties中仅仅是brokername的改变 配置中brokerID = 0 默认master id > 0 默认为从 *********启动从节点************** 如果需要启动从节点可以将启动conf的文件夹直接更换../conf/2m-noslave -2 2m-2s-async 因为master的配置一样可以不动，从节点的需要变动properties需要使用名称后跟-s的 sh mqbroker -n "localhost:9876;另一个nameserver的地址与端口;第三个nameserver的地址与端口" -c ../conf/2m-2s-async/broker-a-s.properties --enable-proxy 通过brokername保证从节点跟随master节点 ********************************** ************如果想要单独部署proxy********** 直接去掉broker 启动命令的--enable-proxy broker 直接启动即可 broker 使用8080 与 8081端口 sh mqproxy -n "localhost:9876;另一个nameserver的地址与端口;第三个nameserver的地址与端口" ************************* ======================================= rocketmq启动endpoint 链接的是proxy地址 ======================================= 单机直接启动 1. 启动nameserver直接在解压bin目录中 sh mqnamesrv namesrv 默认地址工作地址9876 2. 启动broker： sh mqbroker -n localhost:9876 --enable-proxy -n 是当前执行程序指定namerserver监听端口 broker默认工作地址：10911 --enable-proxy proxy代理地址8081 8081被占用时需要指定其他端口新建 conf/proxyConfig.json proxyConfig.json内容如下即可： { "grpcServerPort": 9878 } nohup bin/mqbroker -n 127.0.0.1:9876 -pc conf/proxyConfig.json --enable-proxy & 3. 使用mqadmin 指定broker创建topic -b 一定要使用broker的工作监听地址，不能使用9092，这是与nameserver交互的端口 如下 sh mqadmin updateTopic -n localhost:9876 -t test-normal-topic-1 -c DefaultCluster -a +message.type=NORMAL 4. rocketmq的dashboard必须要再linux环境下打包idea不行 5. NameServer：NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。 Broker：分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master， Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。 Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。 Master 支持读写， Slave 只支持读。 Producer：Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息， 并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。 Consumer：Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息， 并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息， 也可以从Slave订阅消息，订阅规则由Broker配置决定 ===========关于生产组与消费组======= 二者之间是接偶的，没有任何关联的 初始化生产者并不需要设置topic，保证消息topic即可 ======== 关于 rocketmq 集群 ================ 1. rocketmq 有多个集群模式 ： 多主模式（无从）性能最高 但磁盘损坏会丢失消息， 多主多从 异步复制， 消息投递到主broker 会立刻应答成功， 异步复制给从 broker ，极端情况下主broker 未同步消息给从broker 会丢失少量消息 多主多从 同步复制， 消息投递到主broker 并等待主broker同步给从broker 成功后才应答成功，性能不高，但不会丢失消息 以上模式无法自动切换主从 Dleader模式 Dleader模式 ： 集群中只有一个leader 消息投递到leader broker 会立刻应答成功 leader broker 挂掉后，会自动切换为从broker 可以设置主从同步复制 2. rocketmq 可以设置队列数 ，也可有默认队列数，会把队列均分在broker中 在集群模式下需要根据集群规模，设置合理的队列数量以保证消息的均匀分配 一个集群中有2个broker 会通过均分队列到两个broker中 ==============顺序消费============ 1. rocketmq的顺序消费需要设置FiFo的topic模式 2. 必须要设置生产message消息组，rocketmq 会根据 '消息组' 经过算法投递到不同的队列中 ，所以队列中消息是顺序的，rocketmq5 不支持指定队列消费与投递 投递逻辑下沉到proxy中自动计算 ，4 中可以通过指定队列进行保持一致 sh mqadmin updateTopic -n localhost:9876 -t test_topic_FIFO_1 -c DefaultCluster -a +message.type=FIFO 3. Queue1 的消息组 G1 中有四条顺序消息。它们的保存顺序用 M1 到 M4 表示。 在消费过程中，当消息 M1 和 M2 被消费者 A1 处理时，如果 M1 和 M2 的消费状态未提交 ，消费者 A2 无法并行消费消息 M3 和 M4。只有当前面消息的消费状态提交后，消费者才能消费后面的消息。 4. 设置消息组会会根据消息组均分消息到各个队列 5.0中的消费组会均分统一主题下的队列，组中的每一个实例会均分每一个队列 5. 但是要保证串行消费 6. 使用 pushconsumer 会因并发消息导致消息乱序 ，需要使用reentrantlock 并且设置 为公平锁 7. 还会出现消息乱序是因为消息因某种原因导致多次投递，可以从messageView.getDeliveryAttempt() 看出