rocketmq部署

部署RocketMQ的管理工具 RocketMQ提供了UI管理工具，名为rocketmq-console，项目地址：https://github.com/apache/rocketmq-externals/tree/master/rocketmq-console 该工具支持docker以及非docker安装，这里我们选择使用docker安装 #拉取镜像 docker pull styletang/rocketmq-console-ng:1.0.0 #创建并启动容器 docker run -e "JAVA_OPTS=-Drocketmq.namesrv.addr=172.16.55.185:9876 - Dcom.rocketmq.sendMessageWithVIPChannel=false" -p 8082:8080 -t styletang/rocketmqconsole- ng:1.0.0 通过浏览器进行访问：http://172.16.55.185:8082/#/ 切换语言到中文，所有的功能就一目了然了。 来源： CSDN 作者： Leon_Jinhai_Sun 链接： https://blog.csdn.net/Leon_Jinhai_Sun/article/details/104118208

转载请注明来源： http://blog.csdn.net/loongshawn/article/details/51086876 相关文章： 《RocketMQ 消息队列单机部署及使用》 《 java编写简单消息队列。实现高德坐标变形服务》 0 RocketMQ简单介绍 0.1 介绍 RocketMQ是一个消息中间件。 消息中间件中有两个角色：消息生产者和消息消费者。RocketMQ里相同有这两个概念。消息生产者负责创建消息并发送到RocketMQ服务器。RocketMQ服务器会将消息持久化到磁盘，消息消费者从RocketMQ服务器拉取消息并提交给应用消费。 0.2 特点 RocketMQ是一款分布式、队列模型的消息中间件，具有下面特点： 支持严格的消息顺序 支持Topic与Queue两种模式 亿级消息堆积能力 比較友好的分布式特性 同一时候支持Push与Pull方式消费消息 历经多次天猫双十一海量消息考验 0.3 部署结构 上图所看到的为RocketMQ的部署结构，图中Meta字样为RocketMQ早期代号。 1 RocketMQ 消息队列单机部署 1.1 系统配置环境 主机：Linux 内存：8G 硬盘：250G CPU：4核 1.2 须要用到的软件包和文档 眼下在Github上可下载最新的安装包alibaba-rocketmq-3.2.6.tar 下载地址： https:/

1 、 RocketMQ 介绍 1.1. 简介 RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点： 能够保证严格的消息顺序 提供丰富的消息拉取模式 高效的订阅者水平扩展能力 实时的消息订阅机制 亿级消息堆积能力 选用理由： 强调集群无单点，可扩展，任意一点高可用，水平可扩展。 海量消息堆积能力，消息堆积后，写入低延迟。 支持上万个队列 消息失败重试机制 消息可查询 开源社区活跃 成熟度（经过双十一考验） 1.2. 关键概念 1.2.1. 主题与标签 主题Tpoic：第一级消息类型，书的标题 标签Tags：第二级消息类型，书的目录，可以基于Tag做消息过滤 例如： 主题：订单交易 标签：订单交易-创建 订单交易-付款 订单交易-完成 1.2.2. 发送与订阅群组 生产组： 用于消息的发送。 消费组： 用于消息的订阅处理。 生产组和消费组，方便扩缩机器，增减处理能力，集群组的名字，用于标记用 途中的一员。每次只会随机的发给每个集群中的一员。 2 、 RocketMQ 集群方式 推荐的几种 Broker 集群部署方式，这里的Slave 不可写，但可读，类似于 Mysql 主备方式。 2.1.单个 Master 这种方式风险较大，一旦Broker 重启或者宕机时，会导致整个服务不可用，不建议线上环境使用。 2.2.多 Master 模式 一个集群无 Slave，全是

1.RocketMQ简介 RocketMQ是Apache RocketMQ֢作为阿里开源的一款高性能、高吞吐量的分布式消息中间件 特点： 支持Broker和Consumer端消息过滤 支持发布订阅模型，和点对点 支持拉pull和推push两种消息模式 单一队列百万消息、亿级消息堆积 支持单master节点，多master节点，多master多slave节点 任意一点都是高可用，水平拓展，producer，consumer，队列都可以分布式 消息失败重试机制、支持特点level的定时消息 新版本底层采用Netty 4.3.X支持分布式事务 适合金融类业务，高可用性跟踪和审计功能 概念： Producer：消息生成者 Producer Group：消息生产者组，发送同类消息的一个消息生成组 Consumer：消费者 Consumer Group：消息同类消息的多个实例 Tag：标签，子主题(二级分类)对topic的进一步细化，用于区分同一个主题下的不同业务的消息 Topic：主题，如订单类消息，queue是消息的物理管理单位，而topic是逻辑管理单位。一个topic下可以有多个queue, 默认自动创建是4个，手动创建是8个 Message：消息，每个Message必须指定一个Topic Broker：MQ程序，接收生产的消息，提供给消费者消息的程序 Name Server

1、什么是Rocketmq 消息队列 RocketMQ 是阿里巴巴集团自主研发的专业消息中间件，基于高可用分布式集群技术，提供消息订阅和发布、消息轨迹查询以及定时（延时）消息、资源统计、监控报警等一系列消息云服务，是企业级互联网架构的核心产品。 消息队列 RocketMQ 历史超过9年，为分布式应用系统提供异步解耦、削峰填谷的能力，同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性，是阿里巴巴双11使用的核心产品。 2012年开源，2017年成为apache顶级项目。 2、名词解释 以下主要对消息队列 RocketMQ 涉及的专有名词及术语进行定义和解析。 Topic 消息主题，一级消息类型，通过 Topic 对消息进行分类。 Message 消息，消息队列中信息传递的载体。 Message ID 消息的全局唯一标识，由消息队列 RocketMQ 系统自动生成，唯一标识某条消息。 Message Key 消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。 Tag 消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类。 Producer 消息生产者，也称为消息发布者，负责生产并发送消息。 Producer 实例 Producer 的一个对象实例，不同的 Producer 实例可以运行在不同进程内或者不同机器上。Producer

1、为什么要使用消息队列? 主要有三个原因: 解耦、异步、削峰 (1)解耦 传统模式: 传统模式的 缺点 ： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的 缺点 ： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的 缺点 ： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的 优点 ： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析 :一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。 要记住，不要给公司挖坑！ 回答 :回答也很容易，从以下两个个角度来答 系统可用性降低 :你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去

消息队列（Message Queue），简称MQ，本质是一个队列，用于存放数据（message），先入先出（FIFO）。主要用于系统解耦、消息缓存。 目前市面上消息队列的实现有很多种，下面调研了kafka/rabbitMQ/rocketMQ，这三种应用都非常广泛，期望从中选出最合适我们的。 简介 Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。 RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。 RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理

引言 分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,目前对Kafka、RabbitMQ、RocketMQ这三个消息中间件做下对比分析。 - - kafka RocketMQ RabbitMQ 数据来源 相关文章 定位 设计定位 系统间的数据流管道，实时数据处理。 例如：常规的消息系统、网站活性跟踪，监控数据，日志收集、处理等 非日志的可靠消息传输。 例如：订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等 可靠消息传输。和RocketMQ类似。 基础对比 成熟度 日志领域成熟 成熟 成熟 所属社区／公司 Apache Alibaba开发，已加入到Apache下 Mozilla Public License 社区活跃度 高 中 高 来源于网络 API完备性 高 高 高 文档完备性 高 高 高 来源于网络 开发语言 Scala Java Erlang 支持协议 一套自行设计的基于TCP的二进制协议 自己定义的一套 (社区提供JMS--不成熟) AMQP 客户端语言 C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等 Java Java、C、 C++、 Python、 PHP、Perl 等 持久化方式 磁盘文件 磁盘文件 内存、文件 可用性、可靠性比较 部署方式 单机／集群

RocketMQ与Kafka对比（18项差异） 原文链接： https://github.com/alibaba/RocketMQ/blob/master/wiki/kafka_partitions_problem.md 淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。 数据可靠性 RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication Kafka使用异步刷盘方式，异步Replication/同步Replication 总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。

架构设计 1 技术架构 RocketMQ架构上主要分为四部分，如上图所示: Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。 Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。 NameServer：NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息