关注小程序 找一找教程网-随时随地学编程

C/C++教程

常见消息中间件之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的性能瓶颈。
如果感觉对你有帮助点赞支持一下