rocketmq采用的是发布-订阅的模式,不须要每一个消费者维护本身的消息队列,生产者将消息发送到topic,消费者订阅此topic 读取消息。算法
基本概念:数据库
消息模型:消息模型包括producer,consumer,broker三部分。producer生产消息,consumer消费消息,broker存储消息,broker能够是集群部署,其中topic位于broker中服务器
Producer: 通常是业务系统为生产者,将消息投递到broker,投递消息要经历“请求-确认”机制,确保消息不会在投递过程当中丢失。过程:生产者生产消息到broker,broker接受消息写入topic.并发
以后给生产者发送确认相应,若是生产者没有收到服务端的确认或者收到失败的响应,则会从新发送消息;在消费端,消费者在收到消息并完成本身的消费业务逻辑(好比,将数据保存到数据库中)后,也会给服务端发送消费成功的确认,服务端只有收到消费确认后,才认为一条消息被成功消费,不然它会给消费者从新发送这条消息,直到收到对应的消费成功确认。负载均衡
Topic:表示一类消息的集合,每一个主题包含若干条消息,每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位。性能
生产者组:同一类Producer的集合,这类Producer发送同一类消息且发送逻辑一致。若是发送的是事物消息且原始生产者在发送以后崩溃,则Broker服务器会联系同一辈子产者组的其余生产者实例以提交或回溯消费。blog
消费者组:同一类Consumer的集合,这类Consumer一般消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面,实现负载均衡和容错的目标变得很是容易。要注意的是,消费者组的消费者实例必须订阅彻底相同的Topic。RocketMQ 支持两种消息模式:集群消费(Clustering)和广播消费(Broadcasting)队列
具体看一下消息模型图:部署
一、topic中队列的意义?消息队列
1)topic中队列是可配置的,多个队列至关因而负载均衡,将生产者投递到该topic中的消息分别加入各个队列中,图中为2个队列,即至关于将topic的消息承载体分为两段(即每条消息只会往每一个队列里发一次,在topic中是惟一的),这样是为了提供性能,多实例并发生产和消费
2)topic中不能保证消息有序,可是在队列中消息有序
二、消费者组如何消费?
1)同一个消费者组的消费者只能同时有一个消费者获取一个队列的消息,其余的消费者能够获取其余队列的消息。而且每一个消费组本身维护在队列中读取消息的位置
2)每一个消费组都消费主题中一份完整的消息,不一样消费组之间消费进度彼此不受影响,也就是说,一条消息被 Consumer Group1 消费过,也会再给 Consumer Group2 消费。
3)topic中的消息被一个消费组消费完不会删除,应该是全部的消费者组消费完后删除
4)对与一个消费者组来讲,在同一个队列中的消费是串行的,可是多个队列加在一块儿就是并行消费,因此水平扩展能够提升消费性能
三、如何保证读取消息的有序性(一个消费组在一个主题下的多个队列并发消费就没法保证消息的顺序性)?
后台将消息发送到同一队列中(fe:按照订单ID或者用户ID,用一致性哈希算法,计算出队列ID,指定队列ID发送,这样能够保证相同的订单/用户的消息总被发送到同一个队列上,就能够确保严格顺序了。)
四、消息发送确认是否会影响效率?
rocket是批量确认消息的。
因而可知,rocketmq的消息模型简单来讲,producer投递消息到topic中的各个队列,各消费者组订阅topic,消费者组中的消费者并行消费队列中的消息。