十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这篇文章主要为大家展示了“常见消息中间件之RocketMQ有什么用”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“常见消息中间件之RocketMQ有什么用”这篇文章吧。
创新互联公司是专业的长海网站建设公司,长海接单;提供网站制作、做网站,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行长海网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
RocketMQ是一款分布式、队列模型的消息中间件,由阿里巴巴自主研发的一款适用于高并发、高可靠性、海量数据场景的消息中间件。早期开源2.X版本名为MetaQ;2015年迭代3.X版本,更名为RocketMQ,2016年贡献给Apache,经过一年多的孵化,最终成为Apache的顶级开源项目之一。RocketMQ是在Kafka的基础上发展起来的,它的诞生参考借鉴了Apache Kafka(后面的文章我会单独介绍Kafka)。起因是随着阿里巴巴业务的发展,他们发现Kafka对于具体的业务场景支持的不完善,于是阿里巴巴的团队借鉴Kafka的设计思路,并结合自身“双十一”场景,自行开发了更贴合自己业务场景的RocketMQ,对Kafka进行了合理的扩展和API丰富。RocketMQ的消息路由、存储、集群划分等设计思路与Kafka都极其相似,唯一的不同是 RocketMQ 对于业务特性的支持更完善,所以更适用于业务场景。
每一个技术框架,都有它的专有名词,RocketMQ的专业术语如下:
1)Producer:消息生产者,负责产生消息,一般由业务系统负责产生消息。
2)Consumer:消息消费者,负责消费消息,一般由后台系统负责异步消费。
3)Pull Consumer:Consumer的一种,需要主动请求Broker拉取消息。
4)Push Consumer:Consumer的一种,需要向Consumer对象注册监听。
5)Producer Group:生产者集合,一般用于发送一类消息。
6)Consumer Group:消费者集合,一般用于接受一类消息进行消费。
7)Broker:MQ消息服务(中专角色,用于消息存储和生产消费转发)。
1)支持集群模型、负载均衡、水平扩展能力,如下面我们要讲的集群架构。
2)亿级别的消息堆积能力。
3)采用零拷贝的原理、顺序写盘、随机读(索引文件)。
4)丰富的API使用。
5)代码优秀,底层通信框架采用Netty NIO框架。
6)NameServer代替Zookeeper。
7)强调集群无单点,可扩展,任意一点高可用,水平可扩展。
8)消息失败重试机制、消息可查询。
9)开源社区活跃度高,足够成熟(经过双十一考验)。
如下图,我们看一下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工具
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服务。
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有什么用”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注创新互联行业资讯频道!