rocketmq部署

一、环境及准备 集群环境： 软件版本： 部署前操作： 关闭防火墙，关闭selinux(生产环境按需关闭或打开) 同步服务器时间，选择公网ntpd服务器或者自建ntpd服务器 [root@es1 ~]# crontab -l #为了方便直接使用公网服务器 #update time */5 * * * * /usr/bin/rdate -s time-b.nist.gov &>/dev/null 安装配置Java环境 参考此文章配置jvm部分https://www.cnblogs.com/panwenbin-logs/p/10369402.html 配置hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.16.150.134 rocketmq-nameserver1 172.16.150.134 rocketmq-master1 172.16.150.135 rocketmq-nameserver2 172.16.150.135 rocketmq-master2 172.16.150.136 rocketmq

集群支持： 　　RocketMQ天生对集群的支持非常友好 单Master： 　　优点：除了配置简单没什么优点 　　缺点：不可靠，该机器重启或宕机，将导致整个服务不可用 多Master： 　　优点：配置简单，性能最高 　　缺点：可能会有少量消息丢失（配置相关），单台机器重启或宕机期间，该机器下未被消费的消息在机器恢复前不可订阅，影响消息实时性 多Master多Slave异步模式： 　　每个Master配一个Slave，有多对Master-Slave，集群采用异步复制方式，主备有短暂消息延迟，毫秒级 　　优点：性能同多Master几乎一样，实时性高，主备间切换对应用透明，不需人工干预 　　缺点：Master宕机或磁盘损坏时会有少量消息丢失 多Master多Slave同步模式： 　　每个Master配一个Slave，有多对Master-Slave，集群采用同步双写方式，主备都写成功，向应用返回成功 　　优点：服务可用性与数据可用性非常高 　　缺点：性能比异步集群略低，当前版本主宕备不能自动切换为主。 　　需要注意的是，在RocketMQ里面，1台机器只能要么是Master，要么是Slave。这个在初始的机器配置里面，就定死了。不会像kafka那样存在master动态选举的功能。其中Master的broker id = 0，Slave的broker id > 0

一、NameSever介绍 1.1 NameSever是什么 NameServer 的主要功能是为整个 MQ 集群提供服务协调与治理，具体就是记录维护 Topic 、 Broker 的信息，及监控 Broker 的运行状态，为 client 提供路由能力。 NameServer 之间没有信息同步操作，主要通过 Broker 轮询修改信息。 * Name Server 是一个无状态节点，可集群部署，节点之间无任何信息同步; * Broker 分为 Master 与 Slave，它们是一对多的关系，一个 Master 可以对应多个 Slave。 每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server; * Producer与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Broker Master 建立长连接，且定时向 Master Broker 发送心跳。Producer 完全无状态，可集群部署; * Consumer 与 Name Server 集群中的其中一个节点（随机选择）建立长连接，定期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master

最近看了 @JavaGuide 发布的一篇 『面试官问我如何保证Kafka不丢失消息?我哭了！』 ，这篇文章承接这个主题，来聊聊如何保证 RocketMQ 不丢失消息。 0x00. 消息的发送流程 一条消息从生产到被消费，将会经历三个阶段： 生产阶段，Producer 新建消息，然后通过网络将消息投递给 MQ Broker 存储阶段，消息将会存储在 Broker 端磁盘中 消息阶段， Consumer 将会从 Broker 拉取消息 以上任一阶段都可能会丢失消息，我们只要找到这三个阶段丢失消息原因，采用合理的办法避免丢失，就可以彻底解决消息丢失的问题。 0x01. 生产阶段 生产者（Producer） 通过网络发送消息给 Broker，当 Broker 收到之后，将会返回确认响应信息给 Producer。所以生产者只要接收到返回的确认响应，就代表消息在生产阶段未丢失。 RocketMQ 发送消息示例代码如下： DefaultMQProducer mqProducer=new DefaultMQProducer("test"); // 设置 nameSpace 地址 mqProducer.setNamesrvAddr("namesrvAddr"); mqProducer.start(); Message msg = new Message("test_topic" /* Topic

Astrotrain概述 Astrotrain是基于阿里巴巴开源项目RocketMQ进行封装的分布式消息中间件系统，提供集群环境下的消息生产和消费功能。 RocketMQ介绍 RocketMQ的物理部署结构 Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。所有的主题和broker节点信息都由Name Server进行维护。 Broker 是主要的功能单元，处理主题的存储和消费逻辑，Broker会定时同步所有信息至Name Server。 一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致。 一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致。Consumer群组内多应用之间消息消费是竞争关系，Consumer群组之间是共享消费，这点非常重要。 RocketMQ存储特点 Broker上绑定具体的Topic。 Topic下有多个物理存储队列(Queue)，所有存储队列都会存储消息，一个消息只会存储一份。Topic可以分布在不同Broker上。 存储队列的选择决定了消费的特性，如果只读写一个队列，那么消费就是顺序的了，否则会是无序的。 消费者Push和Pull的区别 Push模式下的消息是由事件触发，有消息到达时监听器会被调用(MessageListener)。

简介： RocketMQ（Metaq3.0版本改名）是一款分布式队列模型的消息中间件 特点如下： 1.保证消息顺序 2.支持消息拉取模式 3.高效的订阅者水平和扩展能力 4.实时的消息订阅机制 5.亿级的消息堆积能力 RocketMQ低延迟、高可靠、可伸缩、易于使用的消息中间件。具有以下特性： 1.强调集群无单点，可扩展，任意一点高可用，水平可扩展。 2.海量消息堆积能力，且堆积后写入低延迟。 3.支持上万个队列。（api丰富） 4.消息失败重试机制。 5.消息可查询。 6.开源社区活跃，成熟度高（双十一访问压力）。-- oceanbase 7.支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型 8.在一个队列中可靠的先进先出（FIFO）和严格的顺序传递 9.支持拉（pull）和推（push）两种消息模式 10.单一队列百万消息的堆积能力 11.支持多种消息协议，如 JMS、MQTT 等 12.分布式高可用的部署架构,满足至少一次消息传递语义 13.提供 docker 镜像用于隔离测试和云集群部署 14.提供配置、指标和监控等功能丰富的 Dashboard 专业术语 Producer 消息生产者，生产者的作用就是将消息发送到 MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。 Producer

架构 概念模型 最基本的概念模型与扩展后段概念模型 存储模型 RocketMQ吐血总结 User Guide RocketMQ是一款分布式消息中间件，最初是由阿里巴巴消息中间件团队研发并大规模应用于生产系统，满足线上海量消息堆积的需求， 在2016年底捐赠给Apache开源基金会成为孵化项目，经过不到一年时间正式成为了Apache顶级项目；早期阿里曾经基于ActiveMQ研发消息系统， 随着业务消息的规模增大，瓶颈逐渐显现，后来也考虑过Kafka，但因为在低延迟和高可靠性方面没有选择，最后才自主研发了RocketMQ， 各方面的性能都比目前已有的消息队列要好，RocketMQ和Kafka在概念和原理上都非常相似，所以也经常被拿来对比；RocketMQ默认采用长轮询的拉模式， 单机支持千万级别的消息堆积，可以非常好的应用在海量消息系统中。 NameServer可以部署多个，相互之间独立，其他角色同时向多个NameServer机器上报状态信息，从而达到热备份的目的。 NameServer本身是无状态的，也就是说NameServer中的Broker、Topic等状态信息不会持久存储，都是由各个角色定时上报并 存储到内存中的(NameServer支持配置参数的持久化，一般用不到)。 为何不用ZooKeeper？ZooKeeper的功能很强大，包括自动Master选举等

1、创建一个本地文件夹 在usr/local下，创建rktmq文件夹，当做rocketmq的本地映射目录。（位置或者文件名可自行定义） 2、安装 Namesrv 拉取镜像: $ docker pull rocketmqinc/rocketmq:4.4.0 启动namesrv: $ docker run - d - p 9876:9876 - v { RmHome } / data / namesrv / logs: / root / logs - v { RmHome } / data / namesrv / store: / root / store -- name rmqnamesrv - e "MAX_POSSIBLE_HEAP=100000000" rocketmqinc / rocketmq:4 . 4 . 0 sh mqnamesrv {RmHome} 要替换成你的宿主机想保存 MQ 的日志与数据的地方，通过 docker 的 -v 参数使用 volume 功能，把第一步创建的本地目录映射到容器内的目录上。否则所有数据都默认保存在容器运行时的内存中，重启之后就又回到最初的起点。 docker run - d - p 9876:9876 - v / usr / local / rktmq / data / namesrv / logs: / root / logs - v

一、前言 淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用MySQL作为消息存储媒介，支持水平扩容。为了进一步降低成本，阿里中间件团队认为Notify可进一步优化。 2011年初，Linkedin开源了kafka, 阿里中间件团队在对kafka做了充分的review之后，被kafka的无限消息堆积能力、高效的持久化速度深深吸引，但同时发现kafka主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下，还有若干特性不满足。因此，阿里中间件团队基于Java重新编写了RocketMQ，定位于不仅限于日志场景的可靠消息传输。 目前，RocketMQ在阿里集团被广泛应用于订单、充值、交易、流计算、消息推送、日志流式处理、binlog分发等场景。 二、RocketMQ与kafka的不同 1、数据可靠性 RocketMQ：支持异步实时刷盘、同步刷盘、同步复制、异步复制。 kafka：使用异步刷盘方式，异步复制/同步复制。 总结： 1、RocketMQ支持kafka所不具备的“同步刷盘”功能，在单机可靠性上比kafka更高，不会因为操作系统Crash而导致数据丢失。 2、kafka的同步replication理论上性能低于RocketMQ的replication，这是因为kafka的数据以partition为单位，这样一个kafka实例上可能多上百个partition

基本概念 1 消息模型（Message Model） RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。 2 消息生产者（Producer） 负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。 3 消息消费者（Consumer） 负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。 4 主题（Topic） 表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题