RocketMQ是阿里巴巴技术团队在2016年11月捐赠给Apache基金会,正式成为孵化项目。阿里称会将其打造成顶级的项目,在如今优秀的MQ中间件中,RocketMQ也是占有一席之位的,它具有高性能、高可靠、实时性、分布式的特点,天生为金融互联网领域而生,目前在众多技术团队中都有在使用。
让我们一起进入学习RocketMQ吧!还不知道什么是MQ的同学速度进入什么是消息队列?
RocketMQ的核心概念
producer
生产者,也就是消息的投递者,RcoketMQ提供三种投递消息的方式:同步、异步、单向。
producer group
生产者组,具有相同角色的生产者分组。
consumer
消费者,也就是消息的消费者,从消息队列中拉取消息有两种方式:pull方式,主动从消息队列中批量拉取消息进行消费;push方式,内部封装了拉取消息、消费进度等行为,利用监听器当消息到达时将启动程序消费消息。
consumer group
消费者组,具有相同角色的消费者分组。
broker
RocketMQ-server,也就是RocketMQ的实例,消息队列的载体。
nameserver
nameserver是RocketMQ的一个词汇,nameserver记录broker的列表以及一些元信息,为生产者和消息者查询使用和路由。
讲了那么多,记不住?直接上图理解
消息领域模型
message
消息,消息队列中的消息,也就是生产者和消费者处理的消息。
topic
主题,用于消息的分类,属于消息的第一级分类类型。每条消息必须有一个topic。
tag
标签,也是用于消息的分类,不同于主题的是标签属于消息第二级分类类型,也就是主题的下级分类。为的是给使用者提供额外的灵活性,同时RocketMQ还以根据tag提供消息的查询帮助。
offset
offset是一个消费进度的标识,也就是在消息队列中标识着消费者消费到队列的哪个部位了,由消费者携带着。
消息消费模型
消息的消费方式有两种:集群(Clustering)和广播(Broadcasting)
集群是指一个主题的消息被一个消费者组集群中的一个消费者消费,当这个消费者宕机了,会有在消费者组中相同角色的消费者继续替换掉原来的消费者继续消费。也就是一个消息被一个消费者消费。
广播是指一个主题的消息被消费者组集群中的每个消费者消费,也就是一个消息被多个消费者消费。
消息的有序性
有序消费(orderly):表示从生产者发送的顺序开始到broker的消息队列再到消费者消费的消息具有顺序性。
并发消费(concurrently):表示消息没有顺序性,消费者是并发的消费数据,并发度取决于客户端指定的线程池限制。
RocketMQ的消息流程
首先,nameserver和broker是先建立长连接的,并且nameserver定时发送心跳给broker,从而从broker中获取到broker的元信息,包括broker的主题topic,ip,主从信息等。nameserver更像一个注册中心,存储着broker的元信息。
消费者会优先于生产者开启,确保消息都能被消费,因此,消费者先启动,从nameserver获取broker的元信息,并找到对应的broker对消息进行消费。
最后是生产者启动,同样,生产者也要去nameserver获取broker的元信息,才知道要把哪个主题的消息发送到哪个broker。
高可用架构
在上面的RocketMQ图架构中每个机器都是单机模式,为了应付实际工程中的业务,一般都会采用高可用集群方案,解决掉单点故障的问题。
图片来源于RocketMQ官网
RocketMQ中的每个角色都采用集群的模式。
nameserver之间是没有任何关联的,都是独立的,都存储着broker的元信息。
broker之间会采用主从架构,实现读写分离。消费者会同时对主和从都保持着长连接的,而生产者只会对主保持长连接。
RocketMQ的优势
- 单机吞吐量十万级
- 低延迟,时效性是ms级别
- 可用性非常高,分布式架构
- 消息可靠性,通过优化配置可以做到零丢失
- 功能支持较为完善,拓展性好
- 文档简单
- 支持10亿级别的消息堆积,不会因为堆积导致性能下降
- 源码是使用java写的,可以根据需求进行修改属于自己公司的MQ,可以自己掌握
- 天生为金融互联网领域而生,可靠性和稳定性都很高。
RocketMQ的缺点
- 社区相对来说一般,不是很活跃
- 没有按照标准JMS规范去实现接口,有些系统迁移需要大量的修改代码
- 支持的编程语言客户端不多,目前是java及c++,其中c++不成熟