RocketMQ集群架构与原理解析

最新推荐文章于 2024-05-09 18:21:35 发布

Escape2022

最新推荐文章于 2024-05-09 18:21:35 发布

阅读量661

点赞数

分类专栏：消息中间件文章标签： RocketMQ

本文链接：https://blog.csdn.net/u012413482/article/details/124591018

版权

消息中间件专栏收录该内容

9 篇文章 0 订阅

订阅专栏

初识RocketMQ

RocketMQ是一款分布式、队列模型的消息中间件，由阿里巴巴自主研发的一款适用于高并发、高可靠性、海量数据场景的消息中间件。早期开源2.x版本名为MetaQ;15年迭代3.x版本，更名为Rocket MQ，16年开始贡献到Apache，经过1年多的孵化，最终成为Apach e顶级的开源项目，更新非常频繁，社区活跃度也非常高;目前最新版本为4.5.1-release版本（2019-7-20日前）。RocketMQ参考借鉴了优秀的开源消息中间件Apache Kafka（这也是我们后面课程中重点要讲解的内容哦），其消息的路由、存储、集群划分都借鉴了K afka优秀的设计思路，并结合自身的"双十一"场景进行了合理的扩展和API丰富。

优秀的能力与支持

接下来我们一起来看一下RocketMQ优秀的能力吧~
- 支持集群模型、负载均衡、水平扩展能力
- 亿级别的消息堆积能力
- 采用零拷贝的原理、顺序写盘、随机读（索引文件）
- 丰富的API使用
- 代码优秀，底层通信框架采用Netty NIO框架
- NameServer 代替Zookeeper
- 开源社区活跃度、是否足够成熟（经过双十一考验）

专业术语

任何一种技术框架，都有"她"的专有名词，在你刚开始接触"她"的时候，一定要了解"她"的专业术语，这样能够更快速、更高效的和"她"愉快的玩耍…
- Producer∶消息生产者，负责产生消息，一般由业务系统负责产生消息。
- Consumer∶消息消费者，负责消费消息，一般是后台系统负责异步消费。
- Push Consumer∶Consumer的一种，需要向Consumer对象注册监听。
- Pull Consumer∶Consumer的一种，需要主动请求Broker拉取消息。
- Producer Group∶生产者集合，一般用于发送一类消息。
- Consumer Group∶消费者集合，一般用于接受一类消息进行消费。
- Broker∶MQ消息服务（中转角色，用于消息存储与生产消费转发））。

RocketMQ核心源码包及功能说明

如下图所示，我们要带小伙伴们一起来看看RocketMQ源码包的组成，这样更方便我们日后对他有一个深入的学习。

在这里插入图片描述

- rocketmg-broker主要的业务逻辑，消息收发，主从同步，pag ecache
- rocketmq-client 客户端接口，比如生产者和消费者
- rocketmq-common 公用数据结构等等
- rocketmq-distribution编译模块，编译输出等
- rocketmq-example 示例，比如生产者和消费者
- rocketmq-fliter进行Broker过滤的不感兴趣的消息传输，减小带宽压力
- rocketmq-logappender、rocketmq-logging日志相关
- rocketmq-namesrv Namesrv服务，用于服务协调
- rocketmg-openmessaging 对外提供服务
- rocketmq-remoting 远程调用接口，封装Netty底层通信
-  rocketmq-srvutil提供一些公用的工具方法，比如解析命令行参数
-  rocketmq-store 消息存储核心包
-  rocketmq-test 提供一些测试代码包
-  rocketmq-tools 管理工具，比如有名的mqadmin工具

集群架构模型

RocketMQ为我们提供了丰富的集群架构模型，包括单点模式、主从模式、双主模式、以及生产上使用最多的双主双从模式（或者说多主多从模式），在这里我们仅介绍一下经典的双主双从集群模型，如下图所示∶

-  Producer集群就是生产者集群（他们在同一个生产者组 Producer Group)
-  Consumer集群就是消费者集群（他们在同一个消费者组Consumer Group)
-  NameServer集群作为超轻量级的配置中心，只做集群元数据存储和心跳工作，不必保障节点间数据强一致性，也就是说NameServer集群是一个多机热备的概念。
-  对于Broker而言，通常Master与Slave为一组服务，他们互为主从节点，通过NameServer与外部的Client端暴露统一的集群入口。Broker就是消息存储的核心MQ服务了。

集群架构思考

RocketMQ作为国内顶级的消息中间件，其性能主要依赖于天然的分布式Topic/Queue，并且其内存与磁盘都会存储消息数据，借鉴了Kafka的"空中接力"概念（这个我们后面学习Kafka的时候会详细的说明），所谓"空中接力"就是指数据不一定要落地，RocketM Q提供了同步/异步双写、同步/异步复制的特性。在真正的生产环境中应该选择符合自己业务的配置。下面针对于RocketMQ的高性能及其瓶颈在这里加以说明∶

架构思考∶
- RocketMQ目前本人在公司内部实际生产环境采用8M-8S的集群架构（8主8从）硬件单点Master为32C，96 G内存，500G的SSD
- 其主要瓶颈最终会落在IOPS上面，当高峰期来临的时候，磁盘读写能力是主要的性能瓶颈，每秒收发消息IOPS达到10W+消息，这也是公司内部主要的可靠性消息中间件
- 在很多时候，我们的业务会有一些非核心的消息投递，后续会进行消息中间件的业务拆分，把不重要的消息（可以允许消息丢失、非可靠性投递的消息）采用Kafka的异步发送机制，借助Kafka强大的吞吐量和消息堆积能力来做业务的分流（当然RocketMQ 的性能也足够好）。
- 为什么瓶颈在IOPS?根本原因还是因为云环境导致的问题，云环境的SSD物理存储显然和自建机房SSD会有不小的差距，这一点我们无论是从数据库的磁盘性能、还是搜索服务（ElasticSearch）的磁盘性能，都能给出准确的瓶颈点，单机IOPS达到1万左右就是云存储SSD的性能瓶颈，这个也解释了"木桶短板原理"的效应，在真正的生产中，CPU的工作主要在等待IO操作，高并发下CPU资源接近极限，但是IOPS 还是达不到我们想要的效果。