rocketmq常用命令
启动rocketmq
[root@bogon /]# cd /usr/local/java/rocketmq/bin
[root@bogon bin]# nohup sh mqnamesrv & #启动namesrv
[root@bogon bin]# tail -f ~/logs/rocketmqlogs/namesrv.log #查看日志
[root@bogon bin]# nohup sh broker - n 公网ip -c conf/broker.conf autoCreateTopicEnable=true & #启动broker
[root@bogon bin]# tail -f ~/logs/rocketmqlogs/broker.log #查看日志//第一次启动前需要编辑runbroker.sh和runserver.sh 修改默认JVM大小
[root@bogon bin]# vi runbroker.sh
[root@bogon bin]# vi runserver.sh
关闭rocketmq
sh mqshutdown namesrv
sh mqshuconsumequeuetdown broker
启动broker集群
nohup sh mqbroker -c /usr/local/java/rocketmq/conf/2m-2s-sync/broker-a-s.properties &
优点
- 应用解耦
- 流量削峰
- 数据分发(负载均衡+广播)
缺点：
- 系统引入的外部依赖越多越不稳定且复杂性也大大提高，一旦出现问题后果很严重
- 一致性问题，部分消费者得到但部分消费者没有得到
- 重复消费问题，生产者向rocketmq发生了多条重复的消息
- 顺序性问题
rocket集群搭建：https://blog.csdn.net/kingtok/article/details/104212625
天坑：如果在2台机器a和b上搭建2m-2s结构，通常是a机器配置m1和s2，b机器配置m2和s1，那么这每台机器上不同的broker必须对应不同的store，如store1，store2…store的作用时存储rocketmq的持久化消息，即使一台主机对应了多个broker，那么也要保证这些broker每个对应不同的store
配置文件重点字段
#所属集群名字
brokerClusterName=rocketmq-cluster
#broker名字，同一组也就有一主多从构成的一组，名字时一直的，这个有组名的作用
brokerName=broker-a
#0 表示 Master，>0 表示 Slave
brokerId=0
#nameServer地址，分号分割
#每个broker内部都要通过这种配置主动注册到namesrv集群
namesrvAddr=192.168.141.129:9876;192.168.141.131:9876
#在发送消息时，自动创建服务器不存在的topic，默认创建的队列数
defaultTopicQueueNums=4
#是否允许 Broker 自动创建Topic，建议线下开启，线上关闭
autoCreateTopicEnable=true
#是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭
autoCreateSubscriptionGroup=true
#Broker 对外服务的监听端口,10911代表master broker，11011代表slave broker
listenPort=10911
#删除文件时间点，默认凌晨 4点
deleteWhen=04
#文件保留时间，默认 48 小时
fileReservedTime=120
#存储路径
storePathRootDir=/usr/local/store1/broker-a
#commitLog 存储路径
storePathCommitLog=/usr/local/store1/broker-a/commitlog
#消费队列存储路径存储路径
storePathConsumeQueue=/usr/local/store1/broker-a/consumequeue
#消息索引存储路径
storePathIndex=/usr/local/store1/broker-a/index
#checkpoint 文件存储路径
storeCheckpoint=/usr/local/store1/broker-a/checkpoint
#abort 文件存储路径
abortFile=/usr/local/store1/broker-a/abort、
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
低延迟、高性能和可靠性、万亿级容量同时具备灵活的可伸缩性的分布式消和流处理平台，它由四个部分组成:name servers, brokers, producers 和 consumers。它们所有都可以水平扩展避免单点故障
名称服集群务 NameServer cluster
NameServer服务提供了轻量级的服务发现和路由。每个NameServer服务记录完整的路由信息，提供一致的读写服务，支持快速存储扩展，支持集群搭建。
- broker 管理，nameserver 接受来自broker集群的主动上传的注册信息并提供心跳来检测他们是否可用。
- 路由管理 每一个nameserver都持有关于broker集群和队列的全部路由信息，用来向客户端提供查询。
- NameServer本身是无状态的，也就是说NameServer中的Broker、Topic等状态信息不会持久存储，都是由各个角色定时上报并 存储到内存中的
- ①单个Broker跟所有Namesrv保持心跳请求，心跳间隔为30秒，心跳请求中包括当前Broker所有的Topic信息。Namesrv会反查Broer的心跳信息， 如果某个Broker在2分钟之内都没有心跳，则认为该Broker下线，调整Topic跟Broker的对应关系。但此时Namesrv不会主动通知Producer、Consumer有Broker宕机。②Consumer跟Broker是长连接，会每隔30秒发心跳信息到Broker。Broker端每10秒检查一次当前存活的Consumer，若发现某个Consumer 2分钟内没有心跳， 就断开与该Consumer的连接，并且向该消费组的其他实例发送通知，触发该消费者集群的负载均衡(rebalance)。③生产者每30秒从Namesrv获取Topic跟Broker的映射关系，更新到本地内存中。再跟Topic涉及的所有Broker建立长连接，每隔30秒发一次心跳。 在Broker端也会每10秒扫描一次当前注册的Producer，如果发现某个Producer超过2分钟都没有发心跳，则断开连接。
- Namesrv压力不会太大，平时主要开销是在维持心跳和提供Topic-Broker的关系数据。但有一点需要注意，Broker向Namesrv发心跳时， 会带上当前自己所负责的所有Topic信息，如果Topic个数太多（万级别），会导致一次心跳中，就Topic的数据就几十M，网络情况差的话， 网络传输失败，心跳失败，导致Namesrv误认为Broker心跳失败。
基于以上的功能，producor向rocketmq发生消息时首先时首先经过namesrv，由于namesrv有完整的broker信息和实时状态，可以根据默认或者producor自定义的上传策略将消息写入broker的master类型的服务器中，同理consumer也是根据namesrv安装一定策略从salve类型的broker服务器中取到数据，
所以，所以再master broker，salve broker，producor，consumer这四者中都要配置namesrv的ip+port信息。namesrv协调整个消息传输过程
代理服务集群 Broker Cluster
- Broker通过提供轻量级主题和队列机制来处理消息存储。它们支持Push和Pull模型，包含容错机制(2个副本或3个副本)，提供了极强的峰值处理里能力和按照时间顺序存储数以百万记的消息存储能力，此外，代理提供了灾难恢复、丰富的度量统计和警报机制，这些都是在传统的消息传递系统中缺乏的，
- 它(master)接受并存储来自生产者发送的消息，(slave)出来来自消费者的拉取请求。它也存储和消息有关的信息，包括消费者组，消费位置还有主题队列的信息,Brokers可以按照类别分成两类：master 和slave.，master同时提供读写服务，slave只提供读服务。要部署一个没有单点故障的高可用集群，需要部署多个broker。一个broker集群需要有一个brokerId为0的master和多个brokerId不为0的slave。这个broker集群的主从需要配置相同的brokerName，极端情况下，我们需要保证一个broker集群中至少部署两台brokers服务，每个topic都存在于两个或多个broker中。
生产者集群 Producer Cluster
produce支持分布式部署，分布式的produce通过broker集群提供的各种负载均衡策略将消息发送到broker集群中。发送过程支持快速失败是低延迟的。
消费者集群 Consumer Cluster
消费者也支持在推送和者拉取模式下分布式部署，它还支持集群消费和消息广播。提供实时的消息订阅机制，能够满足大多数消费者的需求
主题 topic
- 主题是生产者传递消息和消费者拉动消息的类别。topic与生产者与消费者之间是松耦合的。特别强调，一个主题可以有零个一个或者多个生产者向它发送消息。相反，一个生产者可以向多个不同的主题发送消息。从消费者角度讲，一个主题可以被零个或者一个或者多个消费者组订阅，同样的一个消费者组可以订阅一个或多个主题，只要这个消费者组保持一致的订阅即可。
- 每个主题可设置队列个数，自动创建主题时默认4个，需要顺序消费的消息发往同一队列，比如同一订单号相关的几条需要顺序消费的消息发往同一队列， 顺序消费的特点的是，不会有两个消费者共同消费任一队列，且当消费者数量小于队列数时，消费者会消费多个队列。至于消息重复，在消费端处理。
- Broker上存Topic信息，Topic由多个队列组成，队列会平均分散在多个Broker上。Producer的发送机制保证消息尽量平均分布到 所有队列中，最终效果就是所有消息都平均落在每个Broker上。
消息存储
RocketMQ的消息的存储是由ConsumeQueue和CommitLog配合来完成的，ConsumeQueue中只存储很少的数据，消息主体都是通过CommitLog来进行读写。 如果某个消息只在CommitLog中有数据，而ConsumeQueue中没有，则消费者无法消费，RocketMQ的事务消息实现就利用了这一点。
- CommitLog：是消息主体以及元数据的存储主体，对CommitLog建立一个ConsumeQueue，每个ConsumeQueue对应一个（概念模型中的）MessageQueue，所以只要有 CommitLog在，ConsumeQueue即使数据丢失，仍然可以恢复出来。
- ConsumeQueue：是一个消息的逻辑队列，存储了这个Queue在CommitLog中的起始offset，log大小和MessageTag的hashCode。每个Topic下的每个Queue都有一个对应的 ConsumeQueue文件，例如Topic中有三个队列，每个队列中的消息索引都会有一个编号，编号从0开始，往上递增。并由此一个位点offset的概念，有了这个概念，就可以对 Consumer端的消费情况进行队列定义。
消息message
消息是传递的信息。消息必须有一个主题，可以理解为你写信事邮寄的地址。消息也可能有一个标签选项是额外的键值对。例如，你可能发送一条消息时设置一个key标记，并通过这个key在broker中筛选这条消息，用来处理特定的业务。（觉得这么翻译更好理解）
消息队列 message queue
主题被划分为一个或多个子主题这就是消息队列。
标签tag
标签可以理解为更细一级的主题，为使用者提供更灵活的查找。有了标签同一业务产生的消息可以有相同的主题不同的标签，不同标签标记的可以有不同的用途。标签可以让你的代码变得清晰连贯，还可以给RocketMQ提供更好的查询支持。
rocketMQ客户端（生产者/消费者）会从nameserver查询队列的路由信息，客户端是如何知道nameserver的地址的呢？
rocketmq集群特点
productor和consumer和namesrv都是无状态节点，也就是没有分工概念的，所以同时启动多态就构成了简单的集群，重点时broker的
- 单master：不可靠
- 多master：配置简单，性能可靠，高可用
- 同步多matser多slave(producor发送的消息master要先落盘然后再同步到slave中，producor才会收到成功信息)，数据实时性更强，安全性更高，broker集群的数据一致性更强，不会有任何数据丢失，效率低于异步形式，
- 异步多matser多slave(producor发送的消息master先落盘后producor就会收到成功信息，然后再同步到slave中),效率更高，但数据安全性低些，master宕机容易丢失部分消息
集群工作原理
- 启动namesrv
rocketmq的java api
导入mq的客户端依赖，因为当前主机同事作为producor和consumer一、生产者端
* 创建生产者对象producor，指定生产者组名
* 指定namesrv地址
* 启动produor
* 创建消息对象，并指定消息的Topic和Tag属性
* 发送消息，分为同步发送、异步发送、单向发送、选择发送前者是消息发送成功才会收到回复；
* 关闭produor注意：1：回复内容主要有①status:发送消息状态 ② msgId：消息唯一表示 ③offset偏移量
④MessageQueue[1,topic=消息类型，由发送的消息时producor来执行,2,brokername=代表producor的消息由namesrv分配到了哪个服务器上，通常是发送到master类型的broker上,3,queueid=队列唯一标识]
2 如果是异步发送那么不会等消息的发送成功而是直接回复producor消息已发送，需要在回调函数中获取到回复信息或者进行异常处理
3 单向发送没有任何回复，如果对发送结果不关心即可采用这种方式如日志二、消费者端
* 创建消费者对象，指定消费者组
* 指定namesrv地址
* 订阅消息，指定消息的Topic和Tag和content
* 设置监听器回调函数处理消息。
* 启动消费者注意：1、消费者类型有推和拉两种，也就是主动和被动接收消息
2、消费者只能接收同组的消息
3、消费者的消息接收分为负载均衡和广播两种模式接收三 rocketmq
* 严格保证消息是有序的①发送一个消息，那么讲消息内容中的数据轮休发送到broker的消息通道中（一个broker有多个消息通道），这种情况不好保证消费者的接收内容顺序
* 全局消息顺序：发送多条消息，只需要这些消息一个个的被消费者接收即可，不保证消息列表的顺序
四 集群工作流程
- 启动namesrv，然后namsrv等待broker，producor，conusmer等来连接，namesrv是管理者，具有路由和状态监控的作用。
- broker启动，跟所有的namesrv集群的namesrv服务器建立长连接，定时向namesrv集群的每个服务器发送心跳包（ip+prot+存储的topic信息），注册成功后namesrv上就有了topic跟broker的映射信息，注意，javaAPI中producor首次发送信息时没有指定topic和broker对应关系时是轮询传输到集群中的master服务器上，当下次重新启动集群时，会通过broker的信息上传在namesrv建立topic和broker的对应关系
- 消息发送前可以先建立topic，并手动指定topic和broker的对应关系，也可以在发消息时自动指定消息的topic，这种情况参考上一点
- producor发送消息，与namesrv集群建立长连接，然后从namesrv哪里得知目标topic所在的broker服务器，每次发送消息轮询从队列链表中选择一个队列，与先关的broker服务器建立连接后向broker发送消息
- consumer启动，与namesrv建立长连接，然后从namesrv哪里得知自己订阅的服务器消息也就是topic存在于那台服务器上，然后直接和broker建立连接来消费消息；
刷盘方式
RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复，又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时候，有两种写磁盘方式：
1）异步刷盘方式：在返回写成功状态时，消息可能只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘操作，快速写入优点是性能高，是缺点Master宕机，磁盘损坏的情况下，会丢失少量的消息, 导致MQ的消息状态和生产者/消费者的消息状态不一致
2）同步刷盘方式：在返回应用写成功状态前，消息已经被写入磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，给应用返回消息写成功的状态。 优点：可以保持MQ的消息状态和生产者/消费者的消息状态一致，缺点是性能比异步的低。同步刷盘还是异步刷盘，是通过Broker配置文件里的flushDiskType参数设置的，参考如上
同步/异步复制
如果一个broker组有Master和Slave，消息需要从Master复制到Slave上，有同步和异步两种复制方式。
1）同步复制方式：等Master和Slave均写成功后才反馈给客户端写成功状态
优点：如果Master出故障，Slave上有全部的备份数据，容易恢复，消费者仍可以从Slave消费, 消息不丢失
缺点：增大数据写入延迟，降低系统吞吐量，性能比异步复制模式略低，大约低10%左右，发送单个Master的响应时间会略高
2）异步复制方式：只要Master写成功即可反馈给客户端写成功状态
优点：系统拥有较低的延迟和较高的吞吐量. Master宕机之后，消费者仍可以从Slave消费，此过程对应用透明，不需要人工干预，性能同多个Master模式几乎一样
缺点：如果Master出了故障，有些数据因为没有被写入Slave，而丢失少量消息。
同步复制和异步复制是通过Broker配置文件里的brokerRole参数进行设置的，这个参数可以被设置成ASYNC_MASTER、SYNC_MASTER、SLAVE三个值中的一个。
关于刷盘方式和复杂方式总结
消息零丢失是一把双刃剑，要想用好，还是要视具体的业务场景，在性能和消息零丢失上做平衡。实际应用中，推荐把Master和Slave设置成ASYNC_FLUSH的异步刷盘方式，主从之间配置成SYNC_MASTER的同步复制方式，这样即使有一台机器出故障，仍然可以保证数据不丢。
rocketmq常用命令相关推荐
- RocketMQ 常用命令实战
本篇整理在运维 RocketMQ 集群时的常用命令,明白命令的含义,在集群运维时得心应手,下面命令均在实际环境中执行过. 集群命令汇总 集群列表 命令 clusterList 用于查看集群各个节点的运 ...
- RocketMQ常用命令使用示例及说明
1. 前言 本文主要为RocketMQ的大部分客户端运维命令的基本使用示例,文中使用的参数为最少必须参数,相关参数会有简单介绍. 本文说明的命令基于RocketMQ的3.5.8版本,有些命令可能在更低 ...
- RocketMQ（一）：Linux安装RocketMQ和常用命令
文章目录 1. 基本概念 2. 安装RocketMQ 2.1 下载 2.2 修改JVM配置 2.3 修改NameSrv和Broker配置 2.4 常用命令 3. 安装RocketMQ-Console ...
- Apache RocketMQ在linux上的常用命令
Apache RocketMQ在linux上的常用命令 进入maven安装后的rocketmq的bin目录 1.启动Name Server 2.启动Broker 3.关闭Name Server 4 ...
- Kubectl 常用命令, 开发人员常用k8s命令
Kubectl 常用命令: 什么是常用,我用的,就是常用的
- docker常用命令详解
docker常用命令详解 本文只记录docker命令在大部分情境下的使用,如果想了解每一个选项的细节,请参考官方文档,这里只作为自己以后的备忘记录下来. 根据自己的理解,总的来说分为以下几种: Doc ...
- 客快物流大数据项目(十五)：DockeFile常用命令
目录 DockeFile常用命令 一.FROM 二.MAINTAINER 三.RUN
- 客快物流大数据项目(九)：Docker常用命令
目录 Docker常用命令 一.帮助命令 二.镜像命令 1.搜索镜像
- linux常用命令（转载）
Linux常用命令大全(非常全!!!) 最近都在和Linux打交道,感觉还不错.我觉得Linux相比windows比较麻烦的就是很多东西都要用命令来控制,当然,这也是很多人喜欢linux的原因,比较短 ...
最新文章
- 0x55. 动态规划 - 环形与后效性处理（例题详解 × 6）
- Laravel 手记（连接mysql）
- python3openpyxl无法打开文件_Python3 处理excel文件(openpyxl库)
- [唐胡璐]Excel技巧 - 使用Excel 2007完成多人协同录入工作
- 飞鸽传书已经写了5年，还是老样子。
- 老师只喜欢好学生（转）
- SQLite 3.31.0 发布，世界上使用量最大的数据库引擎
- c 运算符重载前置++_C ++运算符重载–综合指南
- 【优化算法】粒子群的混沌混合蝴蝶优化算法【含Matlab源码 047期】
- Photoshop DDS转化插件的一些问题
- 疯狂代码 写给WEB2.0的站长
- 切比雪夫不等式例题讲解_人教版初中数学七年级下册一元一次不等式组公开课优质课课件教案视频...
- matlab 报童 泊松分布函数,数学建模和工科数学分析(2)
- 企业建行手机银行怎么对公转账限额
- java中未处理的异常_Java中未处理的异常
- 如何设置VS的唯美背景
- 苹果白屏一直显示苹果_苹果6白屏如何解决，iPhone6白苹果开不了机怎么办
- 软件测试工程师简历要怎么写，才能让 HR 看到?
- 物联网无线技术具体是怎么分类的，主要的应用场景是什么？
- 推荐系统实践Task1：熟悉新闻推荐系统基本流程