B站视频地址
文章目录
- 一、开始
- 二、结果
- 1、RocketMQ 消费关系图
- 1-1、queue和consumer的关系
- 1-2、consumer 和线程的关系
- 2、Kafka 消费关系图
- 1-1、partitions和consumer的关系
- 1-2、consumer 和线程的关系
- 3、RabbitMQ 消费关系图
- 1-1、queue和consumer的关系
- 1-2、consumer 和线程的关系
- 4、总结
- 三、实践
- 1、全局有序
- 2、局部有序
一、开始
先来定义一下何为顺序消息,比如有A、B两条消息,消息处理的流程是 1、2、3 … 10,只有当A消息执行10完毕后,B消息才可以进行1流程。
注:如果A执行到7,B开始执行1,这其实不一定是顺序消息,因为各种原因最终可能导致B先执行完10。
目前比较流行的队列:RocketMQ、RabbitMQ、Kafka
- RocketMQ 消息发送到 topic,再到topic关联的 queue
- RabbitMQ 消息发送到 exchange,再由exchange通过规则到 queue
- Kafka 消息发送到 topic,再到topic关联的 partitions (partitions可以理解就是一个queue)
基于消息队列的规则,想要达到我们的目标就要求A、B两个消息先后发送到同一个 queue/partitions,且只能有一个消费者,且消费的时候必须是单线程非异步的才可满足。
二、结果
三种MQ都支持消息发送到指定的 queue/partition,简单来说就是基于一个标识去计算看它应该落在哪个queue/partition,同一批顺序消息的标识是一样的,所以最终进入的queue/partition也是一致的。 进入 queue/partition 之后的消息都是顺序的,它们是 FIFO的。
顺序消息的控制主要是在消费端,那问题就变成了2个
- queue/partition 和消费者之间是如何对应的
- 消费者对同一个 queue/partition 的消息,是多线程还是单线程
只有满足一个queue/partition 只能对应一个消费者,一个消费者对于一个queue/partition 是单线程消费的,才可以做到消费顺序。
注:MQ有集群消费和广播消费,顺序消费肯定是建立在集群消费模式下的。
最终结果:RocketMQ和Kafka是支持顺序消息的,RabbitMQ不支持顺序消息。
1、RocketMQ 消费关系图
1-1、queue和consumer的关系
从上面的图可以看到,一个queue最多只能对一个 consumer,如果某个 topic需要更大的并发,那就需要,那就增加 queue,然后增加 consumer
1-2、consumer 和线程的关系
正常使用SpringBoot开发项目的时候,都是引入 rocketmq-spring-boot-starter,然后用 @RocketMQMessageListener 来做消费处理,所以下面图也是基于这个用法来画的
通过这个图可以看到使用 @RocketMQMessageListener 做消费者的时候,本质上消息是被多线程去消费了,那就存在A、B消息的真正处理顺序不一致了。
RocketMQ的解决办法是,当你设置消费为顺序消费的时候,在消息处理的时候它会基于 queue加锁,这样就只能单线程处理这个queue的消息了。
设置顺序消费的代码
@RocketMQMessageListener(topic = "Topic1", consumerGroup = "springboot3_producer_group", consumeMode = ConsumeMode.ORDERLY
)
2、Kafka 消费关系图
Kafka 里面没有queue的概念,转而用partitions,但其本质上queue和partitions是一样的,就把它理解成一个queue完事
1-1、partitions和consumer的关系
partitions 和 consumer的关系和 RocketMQ的一模一样,只是把queue改为partitions即可,就不画了
1-2、consumer 和线程的关系
- Kafa消费消息的时候是主动去拉,拉到了就去消费,消费完了,再去拉。 拉和消费的线程是一个
- 当自定义线程数大于 partitions 的时候,没用,这个没用的意思是 Kafka压根不会创建比分配给自己 partitions 数量更多的线程
- 添加消费者的时候,会自平衡(这点所有的MQ都一样的)
- 默认如果没有给consumer设置线程数的话,是单线程
Kafka的解决办法是,每一个 partitions 最多只有一个线程来消费它,单线程自然就是顺序消费的咯。
3、RabbitMQ 消费关系图
1-1、queue和consumer的关系
- RabbitMQ新增了exchange(交换机)的概念,所有的数据都是先发送到交换机,再由exchange基于规则下发到具体的queue
- 可以通过设置交换机的类型的,让消息投递到一个或多个 queue
- 广播消息:可以设置exchange类型为fanout,这样消息就会投递到所有与之绑定的queue(前提是没有设置特殊的 routingkey)
- 集群消费:可以设置多个 consumer去消费一个queue,或一个消费者设置多线程去消费,以此来增加消费速率
注:RabbitMQ的queue和consumer是可以设置为多对多的关系
1-2、consumer 和线程的关系
- RabbitMQ默认也是一个线程消费
- 当开启了多个线程的时候,消息最终顺序就可能不一致,因为各个线程之间其实是相互独立的
4、总结
从上述结果来看其实三种队列都是支持顺序消息的(前提消息都发送到一个 queue/partitions),但支持的程度和结果不同
- RocketMQ,一个queue只能有一个consumer,消费者是多线程的,但开启顺序消费的时候,会对 queue加锁从而保证顺序
- Kafka,一个 partitions只能由一个consumer的一个线程去消费,基于单线程就保证了顺序性
- RabbitMQ,queue和consumer是多对多的,consumer的多个线程是独立的,要想保证顺序,只能让一个queue只有一个consumer,且consumer只有一个线程(但这样做效率就很低)
三、实践
1、全局有序
基于上述分析,三种MQ都可以做到全局有序,因为一旦要求全局有序,消费者就必须是单线程消费。
2、局部有序
比如用户订单业务,对于不同的用户它们的消费顺序可以不用关注,但是对于同一个用户的消息必须是严格有序的(简单的如先下单、再支付)。
对于这种场景RabbitMQ基本上就不满足的,它只有一个队列,如果消费者是单线程的会阻塞其它的消息,一定会造成消息积压。
RocketMQ和Kafka在发送消息的时候都可以指定一个queue/partitions(发消息的时候指定一个key,通过key的hash找一个queue,相同的key得到的就是同一个queue)。
- RocketMQ 通过顺序消息对queue加锁变成单线程消费
- Kafka 的每一个partitions 就只有一个线程去消费
消息可能重复消费这个和顺序消息没关系,所以在写消费逻辑的时候应该做幂等。