常见消息中间件之RocketMQ
前言
RocketMQ是一款分布式、队列模型的消息中间件,由阿里巴巴自主研发的一款适用于高并发、高可靠性、海量数据场景的消息中间件。早期开源2.X版本名为MetaQ;2015年迭代3.X版本,更名为RocketMQ,2016年贡献给Apache,经过一年多的孵化,最终成为Apache的顶级开源项目之一。RocketMQ是在Kafka的基础上发展起来的,它的诞生参考借鉴了Apache Kafka(后面的文章我会单独介绍Kafka)。起因是随着阿里巴巴业务的发展,他们发现Kafka对于具体的业务场景支持的不完善,于是阿里巴巴的团队借鉴Kafka的设计思路,并结合自身“双十一”场景,自行开发了更贴合自己业务场景的RocketMQ,对Kafka进行了合理的扩展和API丰富。RocketMQ的消息路由、存储、集群划分等设计思路与Kafka都极其相似,唯一的不同是 RocketMQ 对于业务特性的支持更完善,所以更适用于业务场景。
1 专业术语
每一个技术框架,都有它的专有名词,RocketMQ的专业术语如下:
1)Producer:消息生产者,负责产生消息,一般由业务系统负责产生消息。
2)Consumer:消息消费者,负责消费消息,一般由后台系统负责异步消费。
3)Pull Consumer:Consumer的一种,需要主动请求Broker拉取消息。
4)Push Consumer:Consumer的一种,需要向Consumer对象注册监听。
5)Producer Group:生产者集合,一般用于发送一类消息。
6)Consumer Group:消费者集合,一般用于接受一类消息进行消费。
7)Broker:MQ消息服务(中专角色,用于消息存储和生产消费转发)。
2 能力与支持
1)支持集群模型、负载均衡、水平扩展能力,如下面我们要讲的集群架构。
2)亿级别的消息堆积能力。
3)采用零拷贝的原理、顺序写盘、随机读(索引文件)。
4)丰富的API使用。
5)代码优秀,底层通信框架采用Netty NIO框架。
6)NameServer代替Zookeeper。
7)强调集群无单点,可扩展,任意一点高可用,水平可扩展。
8)消息失败重试机制、消息可查询。
9)开源社区活跃度高,足够成熟(经过双十一考验)。
3 核心源码包及功能说明
如下图,我们看一下RocketMQ源码包的组成,这有利于我们以后更深入的学习。
1)rocketmq-broker 主要的业务逻辑,消息收发,主从同步,pagecache
2)rocketmq-client 客户端接口,比如生产者和消费者
3)rocketmq-common 公用数据结构等等
4)rocketmq-distribution 编译模块,编译输出等
5)rocketmq-example 示例,比如生产者和消费者
6)rocketmq-fliter 进行Broker过滤的不感兴趣的消息传输,减小带宽压力
7)rocketmq-logappender、rocketmq-logging日志相关
8)rocketmq-namesrv Namesrv服务,用于服务协调
9)rocketmq-openmessaging 对外提供服务
10)rocketmq-remoting 远程调用接口,封装Netty底层通信
11)rocketmq-srvutil 提供一些公用的工具方法,比如解析命令行参数
12)rocketmq-store 消息存储核心包
13)rocketmq-test 提供一些测试代码包
14)rocketmq-tools 管理工具,比如有名的mqadmin工具
4 集群架构
RocketMQ为我们提供了丰富的集群架构模型,包括单点模式、主从模式、双主模式以及生产上使用最多的双主双主模式(或者说多主多从模式),我们来看一下最经典的双主双从模式,如下图:
1)NameServer集群
NameServer集群作为超轻量级的配置中心,存储当前集群所有的Broker信息、Topic与Broker的对应关系。每个NameServer记录完整的路由信息,提供等效的读写服务,并支持快速存储扩展。NameServer只做集群元数据存储和心跳工作,功能简单,稳定性高。多个NameServer之间没有通信,不必保障节点间的数据强一致性,也就是说NameServer集群是一个多机热备的概念,单台NameServer宕机不影响其他NameServer工作。需要注意的是,及时整个NameServer集群宕机了,已经正常工作的Producer、Consumer、Broker仍然能正常工作,但新起的Producer、Consumer、Broker就无法工作。
NameServer采用的是心跳机制,具体如下:
a、单个Broker跟所有NameServer保持心跳请求,心跳间隔为30秒,心跳请求中包括当前Broker所有的Topic信息。需要注意的是,Broker向Namesrv发心跳时, 会带上当前自己所负责的所有Topic信息,如果Topic个数太多(万级别),会导致一次心跳中,就Topic的数据就几十M,网络情况差的话, 网络传输失败,心跳失败,导致Namesrv误认为Broker心跳失败。
b、NameServer会反查Broer的心跳信息, 如果某个Broker在2分钟之内都没有心跳,则认为该Broker下线,调整Topic跟Broker的对应关系。但此时NameServer不会主动通知Producer、Consumer有Broker宕机。
c、Consumer跟Broker是长连接,会每隔30秒发心跳信息到Broker。Broker端每10秒检查一次当前存活的Consumer,若发现某个Consumer 2分钟内没有心跳, 就断开与该Consumer的连接,并且向该消费组的其他实例发送通知,触发该消费者集群的负载均衡(rebalance)。
d、生产者每30秒从Namesrv获取Topic跟Broker的映射关系,更新到本地内存中。再跟Topic涉及的所有Broker建立长连接,每隔30秒发一次心跳。 在Broker端也会每10秒扫描一次当前注册的Producer,如果发现某个Producer超过2分钟都没有发心跳,则断开连接。
2)Producer集群
Producer集群就是消息生产者集群,它们在同一个生产者组Producer Group。Producer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。
3)Consumer集群
Consumer集群就是消息消费者,它们在同一个消费者组Consumer Group。Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接,且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。
4)Broker集群
对于Broker来说,通常Master和Slave为一组服务,它们互为主从节点,通过NameServer与外部的Client端暴露统一的集群入口。Broker就是消息存储的核心MQ服务。
5 总结
RockerMQ作为国内顶级的消息中间件,其性能主要依赖于天然的分布式Topic/Queue,并且其内存与磁盘都会存储消息数据,借鉴了Kafka的“空中接力”概念,就是指数据不一定落地,RocketMQ提供了同步/异步双写、同步/异步复制的特性。在真正的生产环境中应该选择符合自己业务的配置。下面针对RocketMQ的高性能和瓶颈加以说明:
1)在实际生产环境中面临的主要瓶颈最终会落在IOPS上,也就是磁盘读写能力。当高峰期来临,每秒收发消息IOPS达到10W+消息,在云环境上,云环境的SSD物理存储显然和自建机房SSD有着很大的差距,这一点我们无论是从数据库的磁盘性能、还是搜索服务(ElasticSearch)的磁盘性能,都能给出准确的瓶颈点,单机IOPS达到1万左右就是云存储SSD的性能瓶颈,在这里我们也看到了“木桶短板原理”的效应,在真正的生产中,CPU的工作主要在等待IO操作,高并发下CPU资源接近极限,但是IOPS还是达不到我们想要的效果。
2)RocketMQ的性能已经足够好,但是在很多时候,我们的业务会有一些非核心的消息投递,可以进行消息中间件的业务拆分,把不重要的消息(允许消息丢失、非可靠性投递的消息)采用Kafka的异步发送机制,借住Kafka强大的吞吐量和消息堆积能力来做业务分流,以此缓解RocketMQ的性能瓶颈。
常见消息中间件之RocketMQ的更多相关文章
- 消息中间件之 RocketMQ
参考文档: http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/ http://rocketmq.apache.org ...
- 转 消息中间件:RocketMQ 介绍(特性、术语、原理、优缺点、消息顺序、消息重复)
https://blog.csdn.net/jiangyu1013/article/details/81668671 消息中间件的作用 1. 应用解耦 2. 异步处理 比如用户注册场景,注册主流程完成 ...
- 手把手带你了解消息中间件(3)——RocketMQ
一.RocketMQ简介 RocketMQ作为一款纯java.分布式.队列模型的开源消息中间件,支持事务消息.顺序消息.批量消息.定时消息.消息回溯等. 二.RocketMQ架构 如图所示为R ...
- 常见消息中间件之ActiveMQ
前言 消息队列是指利用高效可靠的消息传递机制进行与平台无关的数据交流,并基于数据通信来进行分布式系统的集成.目前消息队列已经逐渐成为企业IT系统内部通信的核心手段,它具有低耦合.可靠投递.广播.流量控 ...
- 消息中间件 MQ
复制粘贴于:https://blog.csdn.net/wqc19920906/article/details/82193316 一.消息中间件相关知识 1.概述 消息队列已经逐渐成为企业IT系统内部 ...
- RocketMQ之消息幂等
幂等(idempotent.idempotence)是一个数学与计算机学概念,常见于抽象代数中. 在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同. 首先我们了解一下什么是 ...
- 消息中间件MQ详解及四大MQ比较
一.消息中间件相关知识 1.概述 消息队列已经逐渐成为企业IT系统内部通信的核心手段.它具有低耦合.可靠投递.广播.流量控制.最终一致性等一系列功能,成为异步RPC的主要手段之一.当今市面上有很多主流 ...
- 消息中间件(一)MQ详解及四大MQ比较
一.消息中间件相关知识 1.概述 消息队列已经逐渐成为企业IT系统内部通信的核心手段.它具有低耦合.可靠投递.广播.流量控制.最终一致性等一系列功能,成为异步RPC的主要手段之一.当今市面上有很多主流 ...
- 消息中间件之MQ详解及四大MQ比较
一.消息中间件相关知识 1.概述 消息队列已经逐渐成为企业IT系统内部通信的核心手段.它具有低耦合.可靠投递.广播.流量控制.最终一致性等一系列功能,成为异步RPC的主要手段之一.当今市面上有很多主流 ...
随机推荐
- JAVA设计模式简介及六种常见设计模式详解
一.什么是设计模式 ...
- ES7异步函数解决进程等待相关业务问题
业务需求场景描述: 在接口只能单一检测的情况下,批量检测资源名称是否存在数据库,如果资源群中某一个资源已存在:给出交互让用户决定是否覆盖资源,最后形成不存在的资源和用户确定覆盖的资源群,进行提交. 业 ...
- map[string]interface{} demo
package main import ( "encoding/json" "fmt" "reflect" ) func demo1() { ...
- 如何配置 SSH 密钥连接 Git 仓库
SSH 是 Secure Shell 的缩写,由 IETF 的网络小组(Network Working Group)所制定:是建立在应用层基础上的安全协议. SSH 是目前较可靠,专为远程登录会话和其 ...
- 独立集(bubble) 题解
问题描述 有一天,一个名叫顺旺基的程序员从石头里诞生了.又有一天,他学会了冒泡排序和独立集.在一个图里,独立集就是一个点集,满足任意两个点之间没有边.于是他就想把这两个东西结合在一起.众所周知,独立集 ...
- 安全可靠国产系统背景下的应用开发应有.NET Core的一席之地
在中美当前背景下的安全可靠国产系统(简称安可),安可产业要实现技术自主可控,需要在四个层面逐步实现:基础硬件设施,如芯片.服务器.存储.交换机.路由器:底层软件,包括操作系统.数据库.中间件等:应用软 ...
- neighbor和neigh_modify(转载)
(转载:http://blog.sina.com.cn/s/blog_b48a7ac30102w4mg.html###) 以下取自:http://simulation.haotui.com/viewt ...
- 微信小程序发送订阅消息(之前是模板消息)
之前的模板消息已经废弃,现在改为订阅消息,订阅消息发布前,需要用户确认后才能接收订阅消息. 小程序端 index.wxml <button bindtap="send"> ...
- Java小菜求职记-以前在Dubbo踩的坑,这次全被问到了,这下舒服了
前传 小林求职记(五)上来就一连串的分布式缓存提问,我有点上头.... 终于,在小林的努力下,获得了王哥公司那边的offer,但是因为薪水没有谈妥,小林又重新进入了求职的旅途,在经历了多次求职过程之后 ...
- go语言之抛出异常
一: panic和recover 作用:panic 用来主动抛出错误: recover 用来捕获 panic 抛出的错误. 概述: ,引发panic有两种情况 )程序主动调用panic函数 )程序产生 ...