下载地址:https://www.oracle.com/java/technologies/javase/javase-jdk8-downloads.html
一、RocketMQ基础知识介绍 Apache RocketMQ是阿里开源的一款高性能、高吞吐量、队列模型的消息中间件的分布式消息中间件。RocketMQ具有以下特点: 上图是一个典型的消息中间件收发
单机版RocketMQ搭建详见:Centos7.6搭建RocketMQ4.8全纪录
之前的文章已对RocketMQ做了详细介绍,这里就不再赘述了,下面是本人在测试和生产环境下RocketMQ3.4.6高可用集群的部署手册,在此分享下:
在生产环境中为了保障集群无单点故障问题,保证高可用性,需要采用双主双从模式来构建RocketMQ集群。双主双从模式部署需要四台机器,两台机器分别部署Broker-Master & NameServer,另外两台机器分别部署Broker-Slave & NameServer。
RocketMQ为我们提供了丰富的集群架构模型,包括单点模式、主从模式、双主模式以及生产上使用最多的双主双从模式(或者说多主多从模式)。更多细节可以查看我之前的文章:云原生中间件RocketMQ(二)源码包结构和集群架构模型。本文主要讲双主模式和多主多从模式的部署。
进入rocket的github官方地址:https://github.com/apache/rocketmq 可以看到当前最新的 releases 版本是4.9.4,下载最新的源码包到本地。
这种部署方式风险较大,一旦Broker重启或者宕机时,会导致整个服务不可用,影响Producer和Consumer的使用。一般用于本地测试,线上环境不推荐使用。
我们的RocketMQ集群为4.6.0版本,按照3个nameserver,2个broker,每个broker为主从双节点部署。
上周花了一点时间从头到尾、从无到有地搭建了一套RocketMQ的环境,觉得还挺easy的,所以就写篇文章分享给大家。
RocketMQ作为阿里系的一款开源的MQ中间件,经历了双十一的高并发场景的消息流转,能够处理万亿级别的消息。
上次我们一起了解了RocketMQ的基本架构原理,那简单的回顾一下RocketMQ的架构组成。
RocketMQ是一款基于分布式架构设计的消息中间件,它能够处理大规模消息流并提供低延迟的消息传递。以下是RocketMQ的主要技术架构组件:
前面几篇文章分享了kafka 相关的实现逻辑,kafka在大吞吐量方面有较好的表现,但是有时候我们需要实现比较复杂的业务逻辑从而对于吞吐量方面要求不是太高,这个时候我们就可以选择RocketMQ.
NameServer 是一个 Broker 与 Topic 路由的注册中心,支持 Broker 的动态注册与发现,主要功能如下:
本文将深入剖析rocketmq为什么选择自己开发NameServer,而不是选择类似于ZK这样的开源组件。同时对rocketmq的路由注册、路由发现、路由剔除进行剖析。并通过结合核心源码,对笔者的观点进行验证。同时对不同类型消息的重试机制,以及客户端选择nameserver的策略进行深入讲解。
本文是《一张图解析 RocketMQ》系列的第 1 篇,今天的内容主要分为三个部分:
如果你还没有安装 Docker,请先安装。可以参考官方文档 https://docs.docker.com/install/ 进行安装
有了NameServer,生产者和消费者只需要通过NameServer建立连接无需关心BrokerServer.类似Spring Cloud中注册中心和服务之间的关系一样,也方便后期做拓展集群.
mq有很多,近期买了《分布式消息中间件实践》这本书,学习关于mq的相关知识。mq大致有有4个功能:
我们熟知的几种常见的消息队列组件,比如Kafka,ActiveMQ,RabbitMQ等,都是一种基于主题的发布订阅机制,RocketMQ也正是基于这种机制实现的消息服务。消息生产者(Producer)将生产好的消息发布到某个主题,该主题下的消息在消息服务器(Broker)中进行传送或存储,由消费者(Consumer)进行订阅主题,从消息服务器中获取到消息后进行消费。消费者获取消息的方式通常有两种,一种是主动去消息服务器拉取消息(Pull Message),另外一种是由消息服务器推送消息(Push Message)给消费者。这种主题的发布订阅机制应用到分布式系统中,成功解耦了生产者和消费者。既然是分布式系统,那么常常存在分布式系统问题,比如某个消息服务器宕机了,生产者是如何感知这台消息服务器宕机了,从而避免将消息发送到这台消息服务器上,消费者是如何感知这台消息服务器宕机了,从而避免从这台消息服务器上拉取消息的呢?且这台宕机的消息服务器是如何从消息服务器实例列表中被剔除的呢?这一切都将归功于NameServer,它的诞生让动态感知、动态剔除、负载均衡成为可能。 图1-1是RocketMQ常见的物理部署图(图片来源:百度图库),采用的部署方式2m-2s(2Master,2Slave),本小节将根据此图阐述RocketMQ基本的流程原理,后面的小节将深入源码中,从源码中来验证基本流程原理。
RocketMQ 选择了自己写 NameServer 做注册中心而没有选择 Zookeeper,这是为什么呢?
Apache RocketMQ之JMS基本概念及使用:https://www.jianshu.com/p/d2e3fd77c4f4 Apache RocketMQ 基础概念及架构解析:https://www.jianshu.com/p/95ab928960b3 Apache RocketMQ 的基础特性介绍:https://www.jianshu.com/p/570680b32590 Apache RocketMQ 集群搭建(两主两从):https://www.jianshu.com/p/b090138cf52c Apache RocketMQ 刷盘策略与复制策略: https://www.jianshu.com/p/d66b381428bb
本文尝试从Apache RocketMQ的简介、主要组件及其作用、3种部署模式、Controller集群模式工作流程、最佳实践等方面对其进行详细分析。希望对您有所帮助!
这种方式风险较大,一旦Broker重启或者宕机时,会导致整个服务不可用。不建议线上环境使用,可以用于本地测试。
一位7年工作经验的小伙伴去面架构师岗位,被问到这样一道面试题,说”RocketMQ为什么要放弃Zookeeper“。然后,想了很久好像没关注过,也不敢瞎猜。
RocketMQ的基本概念在上一篇中给大家介绍了,这一节将给大家介绍环境搭建。RocketMQ中最基础的就是NameServer,我们先来看看它是怎么搭建的。
NameServer 是专为 RocketMQ 设计的轻量级名字服务,它的源码非常精简,八个类 ,少于1000行代码。
RocketMQ前身是阿里研发的一个队列模型的消息中间件,后开源给apache基金会成为了apache的顶级开源项目,具有高性能、高可靠、高实时、分布式特点。
Apache RocketMQ 是一个分布式消息中间件,其具有低延迟、高性能和可靠性、万亿级容量、灵活的可扩展性特性;它是阿里巴巴在2012年开源的分布式消息中间件,目前已经捐赠给 Apache 软件基金会,并于2017年9月25日成为 Apache 的顶级项目。
RocketMQ是一个统一消息引擎、轻量级数据处理平台。 RocketMQ是⼀款阿⾥巴巴开源的消息中间件。2016年11⽉28⽇,阿⾥巴巴向 Apache 软件基⾦会捐赠RocketMQ,成为 Apache 孵化项⽬。2017 年 9 ⽉ 25 ⽇,Apache 宣布 RocketMQ孵化成为 Apache 顶级项⽬(TLP ),成为国内⾸个互联⽹中间件在 Apache 上的顶级项⽬。它使用Java语言开发,在阿里内部,RocketMQ承接了例如“双11”等高并发场景的消息流转,能够处理万亿级别的消息。
2.4 切换到/usr/local下解压rocketmq压缩包 tar -zxvf xxxxxx
RocketMQ主要有四大核心组成部分:NameServer、Broker、Producer以及Consumer四部分。
看了我们之前的文章,相信小伙伴们对RocketMQ已经有了一个初步的了解,那么今天我们就来聊一聊具体如何来设计一套高可用的生产部署架构。
RocketMQ是阿里巴巴开源的分布式消息中间件。支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。它里面有几个区别于标准消息中件间的概念,如Group、Topic、Queue等。系统组成则由Producer、Consumer、Broker、NameServer等。
今天我们主要介绍一下RocketMQ,关于RocketMQ很多人只知道是阿里开源的一款MQ中间件,实际工作中还是用的RabblitMQ,本文以及接下来几篇文章,我会分享一下RocketMQ相关的知识,详细的介绍一下RocketMQ,希望可以帮助到需要的朋友们。
一、首先准备linux环境 使用了两个虚拟机系统 版本为Centos 7 ip地址固定为192.168.194.128 192.168.194.129
RocketMQ是阿里巴巴在2012年开源的分布式消息中间件,目前已经捐赠给Apache基金会,已经于2016年11月成为 Apache 孵化项目,相信RocketMQ的未来会发挥着越来越大的作用,将有更多的开发者因此受益。
最近在倒腾 RocketMQ 消息队列,小卷了下 RocketMQ 的源码,本篇会带着大家一起看下如何配置好调试源码的环境。
刚才的演示中,我们已经体验到了RocketMQ是如何工作的。这样,我们回头看RocketMQ的集群架构,就能够有更全面的理解了。
准备潜心学习一下消息中间件,于是乎RocketMQ出现在我的眼前,经过了几个双十一的考验,激起了我严重的兴趣!最后的结果就是:我毅然的开启了RocketMQ探索之旅!
发现公司这边的消息中间件采用了aliyun的RocketMQ服务,熟悉开源的同学都知道,RocketMQ是国内最早一批捐献Apache并成功毕业的项目。架构设计参考了kafka的模式,所以如果你了解kafka的架构,对于RocketMQ就可以轻车熟路了,虽然参考了kafka,但是RocketMQ也有很多的升级,比如Broker的注册和发现就采用了内部的NameServer,没有引入更多的第三方依赖,而且添加了诸如消息回溯、事务消息、延时消息等特色功能。由于之前没有接触过RocketMQ(之前一直用的kafka和RabbitMQ),准备研究一番,也为了后面集成spring boot metrics监控RocketMQ客户端信息做准备。研究一个开源项目,最好的方法就是Debug,所以记录下本地搭建RocketMq的调试环境过程
RocketMQ是一款高性能、高吞吐量的分布式消息队列系统,它采用了分布式架构,支持多生产者和消费者并发读写,具有高可用性、高吞吐量、低延迟等特点。本文将对RocketMQ的系统架构进行详细解析。
NameServer 维护这些配置信息 、 状态信 息,其他角色都通过 NameServer 来协同执行,这章我们就来分析NameServer以及RocketMQ都通讯机制。
RocketMQ作为一款高性能消息中间件,其核心优势是可靠的消息存储、消息发送的高性能与低延迟、强大的消息堆积能力与消息处理能力、严格的顺序消息模式等。RocketMQ的另一个核心思想是懂得取舍。软件设计不可能做到面面俱到,消息中间件的理想状态是一条消息能且只能被消费一次,但要做到这一点,必然需要牺牲性能。RocketMQ的设计者解决这一难题的办法是不去解决,即保证消息至少被消费一次,但不承诺消息不会被消费者多次消费,其消费的幂等由消费者实现,从而极大地简化了其实现内核,提高了RocketMQ的整体性能。
Apache RocketMQ在4.3.0版中已经支持分布式事务消息,这里RocketMQ采用了2PC的思想来实现了提交事务消息,同时增加一个补偿逻辑来处理二阶段超时或者失败的消息,如下图所示。
发送10000条消息,发送的同时关闭nameserver01,发现消息只发送了367条
RocketMQ5.0中的几个角色NameServer、Broker 和 Proxy,它们的作用如下:
在之前的文章中,已经把 Broker、Producer 和 Conusmer 的部分源码和核心的机制介绍的差不多了,但是其实 RocketMQ 中还有一个比较关键但是我们平时很容易忽略的组件——NameServer。
领取专属 10元无门槛券
手把手带您无忧上云