【RocketMQ】消息中间件基础知识【一】RocketMQ概述【1】MQ简介【2】MQ永用途1限流削峰2异步解耦3数据收集【3】RocketMQ 介绍1RocketMQ 特点2RocketMQ 优势【4】RocketMQ 基本概念1NameServer2Broker3生产者Producer4消费者Consumer5运转流程6名词解释7设计理念8RocketMQ 架构9架构图中集群间交互方式的说明【5】设计目标1架构模式2消息高可用性【二】RocketMQ的安装与启动【1】创建namesrv服务1拉取镜像2创建namesrv数据存储路径3构建namesrv容器【2】创建broker节点1创建broker数据存储路径2创建配置文件3构建broker容器【3】创建rockermq-console服务1拉取镜像2构建rockermq-console容器3需要关闭防火墙或者开放namesrv和broker端口4访问控制台【一】RocketMQ概述【1】MQ简介Message Queue是一种提供消息队列服务的中间件也就是消息中间件是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据一般消息的量不会很大。【2】MQ永用途主要就是以下三点1限流削峰MQ可以把系统的超量请求暂存其中以便系统后期可以慢慢进行处理从而避免了请求的丢失或系统被压垮。2异步解耦上游系统对下游系统额调用若为同步调用则会大大降低系统的吞吐量和并发度并且系统耦合度太高。而异步调用则会解决这些问题。所以两层之间如果要实现由同步到异步的转化一般性做法就是在这两层间添加一个MQ层。3数据收集分布式系统会产生海量级数据流如业务日志、监控数据、用户行为等。针对这些数据流进行实时或批量采集汇总然后对这些数据流进行大数据分析这是当前互联网平台的必备技术。通过MQ完成此类数据收集是最好的选择【3】RocketMQ 介绍1RocketMQ 特点1支持发布/订阅Pub/Sub和点对点P2P消息模型2在一个队列中可靠的先进先出FIFO和严格的顺序传递 RocketMQ可以保证严格的消息顺序而ActiveMQ无法保证3支持拉pull和推push两种消息模式pull其实就是消费者主动从MQ中去拉消息而push则像rabbit MQ一样是MQ给消费者推送消息。但是RocketMQ的push其实是基于pull来实现的。它会先由一个业务代码从MQ中pull消息然后再由业务代码push给特定的应用/消费者。其实底层就是一个pull模式4单一队列百万消息的堆积能力 RocketMQ提供亿级消息的堆积能力这不是重点重点是堆积了亿级的消息后依然保持写入低延迟5支持多种消息协议如 JMS、MQTT 等6分布式高可用的部署架构,满足至少一次消息传递语义RocketMQ原生就是支持分布式的而ActiveMQ原生存在单点性7提供 docker 镜像用于隔离测试和云集群部署8提供配置、指标和监控等功能丰富的 Dashboard2RocketMQ 优势目前主流的 MQ 主要是 RocketMQ、kafka、RabbitMQ其主要优势有1支持事务型消息消息发送和 DB 操作保持两方的最终一致性RabbitMQ 和 Kafka 不支持2支持结合 RocketMQ 的多个系统之间数据最终一致性多方事务二方事务是前提3支持 18 个级别的延迟消息Kafka 不支持4支持指定次数和时间间隔的失败消息重发Kafka 不支持RabbitMQ 需要手动确认5支持 Consumer 端 Tag 过滤减少不必要的网络传输即过滤由MQ完成而不是由消费者完成。RabbitMQ 和 Kafka 不支持6支持重复消费RabbitMQ 不支持Kafka 支持【4】RocketMQ 基本概念RocketMQ主要有四大核心组成部分NameServer、Broker、Producer以及Consumer四部分。1NameServerName Server是一个几乎无状态节点可集群部署节点之间无任何信息同步。NameServer 是整个 RocketMQ 的“大脑” 它是 RocketMQ 的服务注册中心所以 RocketMQ 需要先启动 NameServer 再启动 Rocket 中的 Broker。1NameServer作用名称服务器NameServer用来保存 Broker 相关元信息并给 Producer 和 Consumer 查找Broker 信息。NameServer 被设计成几乎无状态的可以横向扩展节点之间相互之间无通信通过部署多台机器来标记自己是一个伪集群。每个 Broker 在启动的时候会到 NameServer 注册Producer 在发送消息前会根据 Topic 到NameServer 获取到 Broker 的路由信息进而和Broker取得连接。Consumer 也会定时获取 Topic 的路由信息。所以从功能上看应该是和 ZooKeeper 差不多据说 RocketMQ 的早期版本确实是使用的ZooKeeper 后来改为了自己实现NameServer 。2NameServer和zk的区别Name Server和ZooKeeper的作用大致是相同的从宏观上来看Name Server做的东西很少就是保存一些运行数据Name Server之间不互连这就需要broker端连接所有的Name Server运行数据的改动要发送到每一个Name Server来保证运行数据的一致性这个一致性确实有点弱这样就变成了Name Server很轻量级但是broker端就要做更多的东西了。而ZooKeeper呢broker只需要连接其中的一台机器运行数据分发、一致性都交给了ZooKeeper来完成。3高可用保障Broker 在启动时向所有 NameServer 注册主要是服务器地址等 生产者在发送消息之前先从NameServer 获取 Broker 服务器地址列表消费者一样然后根据负载均衡算法从列表中选择一台服务器进行消息发送。NameServer 与每台 Broker 服务保持长连接并间隔 30S 检查 Broker 是否存活如果检测到Broker 宕机则从路由注册表中将其移除这样就可以实现 RocketMQ 的高可用。2Broker消息服务器Broker是消息存储中心主要作用是接收来自 Producer 的消息并存储Consumer 从这里取得消息。它还存储与消息相关的元数据包括用户组、消费进度偏移量、队列信息等。从部署结构图中可以看出 Broker 有 Master 和 Slave 两种类型Master 既可以写又可以读Slave不可以写只可以读。1部署方式Broker部署相对复杂Broker分为Master与Slave一个Master可以对应多个Slave但是一个Slave只能对应一个MasterMaster与Slave的对应关系通过指定相同的Broker Name不同的BrokerId来定义BrokerId为0表Master非0表示Slave。Master也可以部署多个。从物理结构上看 Broker 的集群部署方式有四种单 Master 、多 Master 、多 Master 多Slave同步刷盘、多 Master多 Slave异步刷盘。1-单 Master这种方式一旦 Broker 重启或宕机会导致整个服务不可用这种方式风险较大所以显然不建议线上环境使用。2-多 Master所有消息服务器都是 Master 没有 Slave 。这种方式优点是配置简单单个 Master 宕机或重启维护对应用无影响。缺点是单台机器宕机期间该机器上未被消费的消息在机器恢复之前不可订阅消息实时性会受影响。3-多 Master 多 Slave异步复制每个 Master 配置一个 Slave所以有多对 Master-Slave消息采用异步复制方式主备之间有毫秒级消息延迟。这种方式优点是消息丢失的非常少且消息实时性不会受影响Master 宕机后消费者可以继续从 Slave 消费中间的过程对用户应用程序透明不需要人工干预性能同多 Master 方式几乎一样。缺点是 Master 宕机时在磁盘损坏情况下会丢失极少量消息。4-多 Master 多 Slave同步双写每个 Master 配置一个 Slave所以有多对 Master-Slave 消息采用同步双写方式主备都写成功才返回成功。这种方式优点是数据与服务都没有单点问题Master 宕机时消息无延迟服务与数据的可用性非常高。缺点是性能相对异步复制方式略低发送消息的延迟会略高。2高可用保障每个Broker与Name Server集群中的所有节点建立长连接定时(每隔30s)注册Topic信息到所有Name Server。Name Server定时(每隔10s)扫描所有存活broker的连接如果Name Server超过2分钟没有收到心跳则Name Server断开与Broker的连接。3生产者Producer也称为消息发布者负责生产并发送消息至 Topic。生产者向brokers发送由业务应用程序系统生成的消息。RocketMQ提供了发送同步、异步和单向one-way的多种范例。1同步发送同步发送指消息发送方发出数据后会在收到接收方发回响应之后才发下一个数据包。一般用于重要通知消息例如重要通知邮件、营销短信。2异步发送异步发送指发送方发出数据后不等接收方发回响应接着发送下个数据包一般用于可能链路耗时较长而对响应时间敏感的业务场景例如用户视频上传后通知启动转码服务。假如过一段时间检测到某个信息发送失败可以选择重新发送。3单向发送单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发适用于某些耗时非常短但对可靠性要求并不高的场景例如日志收集。4生产者组生产者组Producer Group是一类 Producer 的集合这类 Producer 通常发送一类消息并且发送逻辑一致所以将这些 Producer 分组在一起。从部署结构上看生产者通过 Producer Group 的名字来标记自己是一个集群。5高可用保障Producer与Name Server集群中的其中一个节点(随机选择)建立长连接定期从Name Server取Topic路由信息并向提供Topic服务的Master建立长连接且定时向Master发送心跳。Producer完全无状态可集群部署。Producer每隔30s由ClientConfig的pollNameServerInterval从Name server获取所有topic队列的最新情况这意味着如果Broker不可用Producer最多30s能够感知在此期间内发往Broker的所有消息都会失败。Producer每隔30s由ClientConfig中heartbeatBrokerInterval决定向所有关联的broker发送心跳Broker每隔10s中扫描所有存活的连接如果Broker在2分钟内没有收到心跳数据则关闭与Producer的连接。4消费者Consumer也称为消息订阅者负责从 Topic 接收并消费消息。消费者从brokers那里拉取信息并将其输入应用程序。1消费者组消费者组Consumer Group一类 Consumer 的集合名称这类 Consumer 通常消费同一类消息并且消费逻辑一致所以将这些 Consumer 分组在一起。消费者组与生产者组类似都是将相同角色的分组在一起并命名。RocketMQ中的消息有个特点同一条消息只能被某一消费组其中的一台机器消费但是可以同时被不同的消费组消费。例如图中的消息就只能被A中的某一台机器消费但是同时也可以被B中的某一台机器消费2高可用保障Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接定期从Name Server取Topic路由信息并向提供Topic服务的Master、Slave建立长连接且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息也可以从Slave订阅消息订阅规则由Broker配置决定。Consumer每隔30s从Name server获取topic的最新队列情况这意味着Broker不可用时Consumer最多最需要30s才能感知。Consumer每隔30s由ClientConfig中heartbeatBrokerInterval决定向所有关联的broker发送心跳Broker每隔10s扫描所有存活的连接若某个连接2分钟内没有发送心跳数据则关闭连接并向该Consumer Group的所有Consumer发出通知Group内的Consumer重新分配队列然后继续消费。当Consumer得到master宕机通知后转向slave消费slave不能保证master的消息100%都同步过来了因此会有少量的消息丢失。但是一旦master恢复未同步过去的消息会被最终消费掉。5运转流程上面介绍了RocketMQ的各个角色及其作用, 下面我们看一下各角色之间完整的交互过程。1-NameServer 先启动2-Broker 启动时向 NameServer 注册3-生产者在发送某个主题的消息之前先从 NamerServer 获取 Broker 服务器地址列表有可能是集群然后根据负载均衡算法从列表中选择一台Broker 进行消息发送。4-NameServer 与每台 Broker 服务器保持长连接并间隔 30S 检测 Broker 是否存活如果检测到Broker 宕机使用心跳机制 如果检测超120S则从路由注册表中将其移除。5-消费者在订阅某个主题的消息之前从 NamerServer 获取 Broker 服务器地址列表有可能是集群但是消费者选择从 Broker 中 订阅消息订阅规则由 Broker 配置决定6名词解释1消息消息Message就是要传输的信息。一条消息必须有一个主题Topic主题可以看做是你的信件要邮寄的地址。一条消息也可以拥有一个可选的标签Tag和额处的键值对它们可以用于设置一个业务 key 并在 Broker 上查找此消息以便在开发期间查找问题。2主题主题Topic可以看做消息的规类它是消息的第一级类型。比如一个电商系统可以分为交易消息、物流消息等一条消息必须有一个 Topic 。Topic 与生产者和消费者的关系非常松散一个 Topic可以有0个、1个、多个生产者向其发送消息一个生产者也可以同时向不同的 Topic 发送消息。一个Topic 也可以被 0个、1个、多个消费者订阅。3标签标签Tag可以看作子主题它是消息的第二级类型用于为用户提供额外的灵活性。使用标签同一业务模块不同目的的消息就可以用相同 Topic 而不同的 Tag 来标识。比如交易消息又可以分为交易创建消息、交易完成消息等一条消息可以没有 Tag 。标签有助于保持您的代码干净和连贯并且还可以为 RocketMQ 提供的查询系统提供帮助。简单来说TOPIC可以看作衣服而TAG可以看作衣服下的【短袖】、【外套】、【卫衣】等4消息队列消息队列Message Queue主题被划分为一个或多个子主题即消息队列。一个 Topic 下可以设置多个消息队列发送消息时执行该消息的 Topic RocketMQ 会轮询该 Topic 下的所有队列将消息发出去。下图 Broker 内部消息情况其实Topic只是一个逻辑上的概念下面的消息队列才是真正的实体。5消息消费模式消息消费模式有两种集群消费Clustering和广播消费Broadcasting默认情况下就是集群消费该模式一条消息只能被某一消费者组中的某一台机器消费如果某个消费者挂掉分组内其它消费者会接替挂掉的消费者继续消费。而广播消费消息会发给消费者组中的每一个消费者进行消费。6消息顺序消息顺序Message Order有两种顺序消费Orderly和并行消费Concurrently。顺序消费表示消息消费的顺序和生产者为每个消息队列发送信息时候的顺序一致所以如果正在处理全局顺序是强制性的场景需要确保使用的主题只有一个消息队列。并行消费不再保证消息顺序消费的最大并行数量受每个消费者客户端指定的线程池限制。7设计理念RocketMQ 的设计基于主题的发布与订阅模式其核心功能包括消息发送、消息存储(Broker)、消息消费整体设计追求简单与性能第一主要体现在以下三个方面1NameServer设计及其简单RocketMQ摒弃了业界常用的zookeeper作为注册中心而是使用自研的NameServer来实现元数据的管理因为Topic路由信息无须在集群间保持强一致性追求最终一致性并且能容忍分钟级的不一致所以RocketMQ的NameServer集群间互不通信极大降低了设计的复杂度降低了对网络的要求提升性能。2高效的IO存储机制RocketMQ追求消息发送的高吞吐量RocketMQ消息存储文件设计成文件组的概念组内单个文件大小固定方便引入内存映射机制。所有主题的消息存储基于顺序写提升写性能同时为了兼顾消息消费与消息查找引入了消息消费队列文件与索引文件。3容忍存在的设计缺陷适当将某些工作下放给RocketMQ使用者。消息中间件的实现者经常会遇到一个难题如何保证消息一定能被消息消费者消费并且保证只消费一次。 RocketMQ的设计者给出的解决办法是不解决这个难题而是退而求其次只保证消息被消费者消费但设计上允许消息被重复消费如果你们要用RocketMQ那么你们自己在消费端用逻辑实现只消费一次的功能。8RocketMQ 架构RocketMQ 架构图中展示了四个集群1NameServer 集群提供轻量级的服务发现及路由每个 NameServer 记录完整的路由信息提供相应的读写服务支持快速存储扩展。NameServer是一个功能齐全的服务器主要包含两个功能1-Broker 管理接收来自 Broker 集群的注册请求提供心跳机制检测 Broker 是否存活2-路由管理每个 NameServer 持有全部有关 Broker 集群和客户端请求队列的路由信息2Broker 集群通过提供轻量级的 Topic 和Queue 机制处理消息存储。同时支持推Push和拉Pull两种模型包含容错机制。提供强大的峰值填充和以原始时间顺序累积数千亿条消息的能力。此外还提供灾难恢复丰富的指标统计数据和警报机制这些都是传统的消息系统缺乏的。Broker 有几个重要的子模块1-远程处理模块Broker 入口处理来自客户端的请求2-客户端管理管理客户端包括消息生产者和消费者维护消费者的主题订阅3-存储服务提供在物理硬盘上存储和查询消息的简单 API4-HA 服务提供主从 Broker 间数据同步5-索引服务通过指定键为消息建立索引并提供快速消息查询3Producer 集群消息生产者支持分布式部署分布式生产者通过多种负载均衡模式向 Broker 集群发送消息。4Consumer 集群消息消费者也支持 Push 和 Pull 模型的分布式部署还支持集群消费和消息广播。提供了实时的消息订阅机制可以满足大多数消费者的需求。9架构图中集群间交互方式的说明1Broker Master 和 Broker Slave 是主从结构会执行数据同步 Data Sync2每个 Broker 与 NameServer 集群中所有节点建立长连接定时注册 Topic 信息到所有NameServer3Producer 与 NameServer 集群中的其中一个节点随机建立长连接定期从 NameServer 获取Topic 路由信息并与提供 Topic 服务的 Broker Master 建立长连接定时向 Broker 发送心跳4Producer 只能将消息发送到 Broker Master但是 Consumer 同时和Broker Master和 Broker Slave 建立长连接既可以从 Master 订阅消息也可以从 Slave 订阅消息。【5】设计目标1架构模式RocketMQ与大部分消息中间件一样采用发布订阅模式基本的参与组件主要包括消息发送者、消息服务器消息存储、消息消费、路由发现。1顺序消息顺序消息FIFOFirst Input First Output是一种严格按照顺序进行发布和消费的消息类型。要求消息的发布和消息消费都按照顺序进行RocketMQ可以严格保证消息有序RocketMQ可以严格的保证消息有序。但这个顺序不是全局顺序只是分区queue顺序。要全局顺序只能一个分区但是同一条queue里面RocketMQ的确是能保证FIFO的。2消息过滤消息过滤是指在消息消费时消息消费者可以对同一主题下的消息按照规则只消费自己感兴趣的消息。RocketMQ消息过滤支持在服务端与消费端的消息过滤机制。1-消息在Broker端过滤Broker只将消息消费者感兴趣的消息发送给消息消费者。2-消息在消息消费端过滤消息过滤方式完全由消息消费者自定义但缺点是有很多无用的消息会从Broker传输到消费端。3消息存储消息中间件的一个核心实现是消息的存储对消息存储一般有如下两个维度的考量消息堆积能力和消息存储性能。RocketMQ追求消息存储的高性能引入内存映射机制所有主题的消息顺序存储在同一个文件中。同时为了避免消息无限在消息存储服务器中累积引入了消息文件过期机制与文件存储空间报警机制。2消息高可用性通常影响消息可靠性的有以下几种情况1-Broker正常关机。2-Broker异常宕机。3-操作系统宕机。4-机器断电但是能立即恢复供电情况。5-机器无法开机可能是CPU、主板、内存等关键设备损坏。6-磁盘设备损坏。针对上述情况情况1,4的RocketMQ在同步刷盘机制下可以确保不丢失消息在异步刷盘模式下会丢失少量消息。情况5,6属于单点故障一旦发生该节点上的消息全部丢失如果开启了异步复制机制RoketMQ能保证只丢失少量消息RocketMQ在后续版本中将引入双写机制以满足消息可靠性要求极高的场合。1消息到消费低延迟RocketMQ在消息不发生消息堆积时以长轮询模式实现准实时的消息推送模式。2确保消息必须被消费一次不是只消费一次RocketMQ通过消息消费确认机制ACK来确保消息至少被消费一次但由于ACK消息有可能丢失等其他原因RocketMQ无法做到消息只被消费一次有重复消费的可能。3回溯消息回溯消息是指消息消费端已经消费成功的消息由于业务要求需要重新消费消息。RocketMQ支持按时间回溯消息时间维度可精确到毫秒可以向前或向后回溯。4消息堆积消息中间件的主要功能是异步解耦必须具备应对前端的数据洪峰提高后端系统的可用性必然要求消息中间件具备一定的消息堆积能力。RocketMQ消息存储使用磁盘文件内存映射机制并且在物理布局上为多个大小相等的文件组成逻辑文件组可以无限循环使用。RocketMQ消息存储文件并不是永久存储在消息服务器端而是提供了过期机制默认保留3天。5定时消息定时消息是指消息发送到Broker后不能被消息消费端立即消费要到特定的时间点或者等待特定的时间后才能被消费。如果要支持任意精度的定时消息消费必须在消息服务端对消息进行排序势必带来很大的性能损耗故RocketMQ不支持任意进度的定时消息而只支持特定延迟级别。6消息重试机制消息重试是指消息在消费时如果发送异常消息中间件需要支持消息重新投递RocketMQ支持消息重试机制。【二】RocketMQ的安装与启动直接使用docker安装【1】创建namesrv服务1拉取镜像docker pull rocketmqinc/rocketmq2创建namesrv数据存储路径mkdir-p/docker/rocketmq/data/namesrv/logs/docker/rocketmq/data/namesrv/store3构建namesrv容器docker run-d \--restartalways \--name rmqnamesrv \-p 9876:9876 \-v/docker/rocketmq/data/namesrv/logs:/root/logs \-v/docker/rocketmq/data/namesrv/store:/root/store \-eMAX_POSSIBLE_HEAP100000000\ rocketmqinc/rocketmq \ sh mqnamesrv-d以守护进程的方式启动1-restartalways| docker重启时候容器自动重启2命令分析-name rmqnamesrv | 把容器的名字设置为rmqnamesrv-p 9876:9876| 把容器内的端口9876挂载到宿主机9876上面-v /docker/rocketmq/data/namesrv/logs:/root/logs | 把容器内的/root/logs日志目录挂载到宿主机的 /docker/rocketmq/data/namesrv/logs目录-v /docker/rocketmq/data/namesrv/store:/root/store | 把容器内的/root/store数据存储目录挂载到宿主机的 /docker/rocketmq/data/namesrv目录rmqnamesrv | 容器的名字-e “MAX_POSSIBLE_HEAP100000000” | 设置容器的最大堆内存为100000000rocketmqinc/rocketmq | 使用的镜像名称sh mqnamesrv | 启动namesrv服务【2】创建broker节点1创建broker数据存储路径mkdir-p/docker/rocketmq/data/broker/logs/docker/rocketmq/data/broker/store/docker/rocketmq/conf2创建配置文件vi /docker/rocketmq/conf/broker.conf# 所属集群名称如果节点较多可以配置多个brokerClusterName DefaultCluster#broker名称master和slave使用相同的名称表明他们的主从关系brokerName broker-a#0表示Master大于0表示不同的slavebrokerId 0#表示几点做消息删除动作默认是凌晨4点deleteWhen 04#在磁盘上保留消息的时长单位是小时fileReservedTime 48#有三个值SYNC_MASTERASYNC_MASTERSLAVE同步和异步表示Master和Slave之间同步数据的机制brokerRole ASYNC_MASTER#刷盘策略取值为ASYNC_FLUSHSYNC_FLUSH表示同步刷盘和异步刷盘SYNC_FLUSH消息写入磁盘后才返回成功状态ASYNC_FLUSH不需要flushDiskType ASYNC_FLUSH# 设置broker节点所在服务器的ip地址brokerIP1 192.168.19.12# 磁盘使用达到95%之后,生产者再写入消息会报错 CODE: 14 DESC: service not available now, maybe disk fulldiskMaxUsedSpaceRatio953构建broker容器docker run-d \--restartalways \--name rmqbroker \--link rmqnamesrv:namesrv \-p 10911:10911 \-p 10909:10909 \-v/docker/rocketmq/data/broker/logs:/root/logs \-v/docker/rocketmq/data/broker/store:/root/store \-v/docker/rocketmq/conf/broker.conf:/opt/rocketmq-4.4.0/conf/broker.conf \-eNAMESRV_ADDRnamesrv:9876\-eMAX_POSSIBLE_HEAP200000000\ rocketmqinc/rocketmq \ sh mqbroker-c/opt/rocketmq-4.4.0/conf/broker.conf1-d以守护进程的方式启动2–restartalwaysdocker重启时候镜像自动重启3-name rmqbroker | 把容器的名字设置为rmqbroker4–link rmqnamesrv:namesrv | 和rmqnamesrv容器通信-p 10911:10911 | 把容器的非vip通道端口挂载到宿主机-p 10909:10909 | 把容器的vip通道端口挂载到宿主机-e “NAMESRV_ADDRnamesrv:9876” | 指定namesrv的地址为本机namesrv的ip地址:9876-e “MAX_POSSIBLE_HEAP200000000” rocketmqinc/rocketmq sh mqbroker | 指定broker服务的最大堆内存rocketmqinc/rocketmq | 使用的镜像名称sh mqbroker -c /opt/rocketmq-4.4.0/conf/broker.conf | 指定配置文件启动broker节点【3】创建rockermq-console服务1拉取镜像docker pull pangliang/rocketmq-console-ng2构建rockermq-console容器需要把192.168.19.12换成部署namesrv机器地址docker run-d \--restartalways \--name rmqadmin \-eJAVA_OPTS-Drocketmq.namesrv.addr192.168.19.12:9876 \ -Dcom.rocketmq.sendMessageWithVIPChannelfalse\-p 9999:8080 \ pangliang/rocketmq-console-ng1-d以守护进程的方式启动2-restartalways| docker重启时候镜像自动重启3-name rmqadmin | 把容器的名字设置为rmqadmin-e “JAVA_OPTS-Drocketmq.namesrv.addr192.168.52.136:9876 | 设置namesrv服务的ip地址-Dcom.rocketmq.sendMessageWithVIPChannelfalse” | 不使用vip通道发送消息–p 9999:8080 | 把容器内的端口8080挂载到宿主机上的9999端口3需要关闭防火墙或者开放namesrv和broker端口如果不设置控制台服务将无法访问namesrv服务有两种方案一种是直接关闭防火墙所有端口都可以访问另一种是开放指定端口。1关闭防火墙systemctl stop firewalld.service2开放指定端口firewall-cmd--permanent--zonepublic--add-port9876/tcp firewall-cmd--permanent--zonepublic--add-port10911/tcp# 立即生效firewall-cmd--reload4访问控制台网页访问http://192.168.19.12:9999/查看控制台信息