active mq topic消费后删除_RocketMQ之广播模式和顺序消费

在之前的文章spring boot整合rocketMQ和Spring Boot整合RocketMQ之事务消息简单介绍了下rocketmq-spring-boot-starter的基本使用，虽然有人说建议使用官方的客户端，但是不得不承认的一点就是rocketmq-spring-boot-starter确实在使用上要更方便一些。上周部门的同事提了一个小小的需求，这个需求的部分功能需要通过消息的广播来完成，这就涉及到了如何使用rocketMQ的广播模式。另外一个需求就是要能够保证消费顺序，因为数据之间有依赖关系。所以自己周末打算自己先研究下rocketMQ的广播消费和顺序消费。

一、前提准备

既然设计到广播消费，那么涉及到的服务肯定不止一个，当然也可以在一个服务中来实现多个不同的消费者实现，不过为了好区分我还是创建了多个项目。
项目比较简单只需要引入基本的依赖和rocketMQ依赖即可，这里就不在粘贴相关内容了，具体的pom.xml可以参考上次文章的部分。另外rocketMQ版本依然使用的是4.4.0，本地启动rocketMQ。最好保证使用的rocketMQ服务器版本和项目中引入的客户端版本一致。
根据需要我创建了三个简单的Spring boot项目。分别是：producer:这个服务用来发送消息，同时也可以消费消息，设置端口号：8081；consumer和mq-consumer:这两个服务都是用来消费MQ发送的消息，设置端口号分别为：8082和8083；

二、广播消费

rocketMQ是支持广播消费的，只需要在消费端进行配置即可，当然我看到有些人也说建议使用集群消费来模拟广播消费，而不是直接使用广播消费。接下来我们看看这二者有什么区别。
首先我在producer服务创建一个消息监听器(可以理解为一个消费者)，代码如下：

@Slf4j

topic的话在配置文件进行了配置，保证每个服务中配置的topic相同即可。
同样，我在consumer服务定义一个和producer完全相同的消费者，代码如下：

@Slf4j

这里只在日志输出做一点区分，默认情况下使用的是集群消费，这就意味着如果我们配置了多个消费者实例，只会有一个实例消费消息。我们可以通过测试一下集群模式下两个服务的日志输出：

图-1.png

通过查看日志发现只有 producer 有日志输出， consumer 是没有的，其实这个就涉及到了负载均衡，这里就不细述了。
接下来我们测试一下使用广播模式，当然如果是要使用广播消费，需要修改配置文件，如下：

@RocketMQMessageListener(consumerGroup = "producer_group",            topic = "${rocketmq.consumer.topic}",            selectorExpression = "tag_A",            messageModel = MessageModel.BROADCASTING)

重新测试日志输出如下：

图-2.png

图-3.png

通过对比 producer 和 consumer 两个服务的日志输出可以看出，使用广播消费会导致所有的消费者都去消费同一条消息，如果所有的服务都是单实例当然是没有问题的，但是如果服务是一个集群就会存在一个问题，比如某个消息需要写库，这样会出现某一个服务会出现多条完全相同的数据，这个其实是没必要的，我们只需要保证一个服务的一个消费者实例消费即可。所以一般不建议直接使用广播模式，而是建议使用集群模式来模拟广播模式。
接下来我们就测试通过使用集群模式来实现消息广播，其实原理还是比较简单，即在每个服务内定义一个消费者组，但是订阅相同的 topic 和 tag 即可。 producer 服务内的消息监听器的消息模式改为集群消费，修改 consumer 服务内的消息监听器修改如下：

@Slf4j

同时在mq-consumer服务内增加一个消息的监听器，一定要保证三个服务的消费组不同，代码如下：

@Slf4j

再次进行测试，三个服务的日志输出如下：

图-4.png

图-5.png

图-6.png

三个服务都消费了发送的消息说明使用集群模式模拟广播模式是成功的，当然感兴趣的话也可以每个服务都启动多个实例测试。

三、顺序消费

rocketMQ的顺序消费包含两种情况，一种是局部有序或者说分区有序，另一种则是全局有序。消息发送时默认会采用轮询的方式将消息发送到不同的queue中。rocketMQ是可以保证分区有序的，即同一个queue里面的所有消息是能保证有序的，而如果想实现全局有序，就需要将所有的消息投递到一个queue中，这样就能保证所有的消息都有序。但是这就会带来一个问题，那就是消息队列的吞吐量下降。
先测试一个普通的消息(不将消息发送到一个queue)消费情况，启动producer和consumer两个应用，分别在添加一个消息监听器用来测试，代码如下：

@Slf4j

上面的代码只是修改了消费者组的名称以及tag值，在consumer服务中单独修改下具体的日志输出，方便我们区分具体之那个消费监听器消费即可。rocketMQ默认的消费模式是并发消费，我们先来测试一下并发消费的情况，通过一个简单的循环发送多条消息，我们看下具体的消费情况是怎么样的，日志输出如下：

图-7.png

图-8.png

对比上面两图中日志的输出情况可以看出，这次测试中共使用了4个queue，序号分别是 0、1、2、3，具体哪一条消息使用了哪个queue我们就不探讨了，用producer的日记举例，producer消费者一共消费了4条消息，其中涉及到的quque编号是0和1，在看编号的queueId=0中的消息，即第3条和第7条消息，在queueId=0的queue中它们的偏移量queueOffset是连续的，说明消费者从队列中消费的时候也是按照顺序消费的。在发送消息的时候通过轮询的方式，将这10条消息放置到了4个quque中。虽然发送消息的时候这10条消息是按顺序发送的，但是因为各消息放入的队列queue不同，每个队列对应的消费者也有所不同，所以整体上消费时是无序的。另外即使是一个消费者实例在消费的时候会启动多个线程消费(默认的最大消费线程是64)这点根据日志中线程编号也能看出端倪。

---

下面测试一下使用顺序发送，即将消息全部放到一个消息队列中，并且在消费者使用顺序消费，发送的代码进行修改，使用RocketMQTemplate的syncSendOrderly方法，这个方法需要制定一个hashKey用来选择对应的队列，这里做测试随便输入一个就好，在实际应用的过程中可以根据具体的业务进行区分。
然后两个服务的消费者监听器进行修改，将消费模式均改为ORDERLY，如下：

@Slf4j

日志输出如下：

图-9.png

这次只有 consumer 的消费者进行消费， producer 没有任何的日志输出。根据日志输出可以看出，发送的10条消息均在 queueId=3 的队列中，且消费完全有序，另外 queueOffset 和消息本身的顺序也能对应上，这个测试的结果还是符合自己预期的。

四、总结

这次主要是根据自己在实际工作中的实际需求来学习rocketMQ的使用，自己通过几个小测试来模拟相应的场景，整体来看使用上还是比较简单的。另外就是自己在测试的过程中确实也遇到了重复消费的情况，这点一定要引起重视，因为rocketMQ是无法避免重复消费的，所以这就要求我们在实际中一定要通过业务判断来避免这种情况。