本章介绍Spring Cloud Stream 消费组和消息持久化,Spring Cloud Stream 入门参考:【SpringCloud】Spring Cloud Stream 消息驱动(二十三)
Spring Cloud Stream消费组
多数情况,生产者发送消息给某具体微服务时只希望被消费一次,按照上面我们启动两个应用的例子,虽然它们同属一个应用,但是这个消息出现了被重复消费两次的情况。为了解决这个问题,在Spring Cloud Stream中提供了消费组的概念
案例说明
本章案例在也是使用上一章的案例,架构如下,其中消息消费者8802与消息消费者8803,应用名称和代码一样,
消息消费者(8802|8803)配置:
1 # 端口 2 server: 3 port: 8802 4 5 spring: 6 application: 7 name: cloud-stream-consumer 8 cloud: 9 stream: 10 binders: 11 # 表示定义的名称,用于binding的服务信息 12 defaultRabbit: 13 # 消息组件类型 14 type: rabbit 15 # 设置rabbitmq的相关配置的环境配置 16 environment: 17 spring: 18 rabbitmq: 19 host: 127.0.0.1 20 port: 5672 21 username: guest 22 password: guest 23 # 服务的整合处理 24 bindings: 25 # 这个名字是一个通道的名称 26 input: 27 # 表示要使用的Exchange 名称定义 28 destination: studyExchange 29 # 设置消息类型,本次为json,文本则设置"text/plain" 30 content-type: application/json 31 # 设置要绑定的消息服务的具体设置 32 binder: defaultRabbit 33 # 消费分组 34 # group: testA 35 36 eureka: 37 client: 38 service-url: 39 defaultZone: http://localhost:8761/eureka
同一消息被同一服务多处消费现象
测试流程:
1、启动相关项目
2、查看Eureka注册中心,同一服务CLOUD-STREAM-CONSUMER,有2个节点
3、查看RabbitMQ的Web后台,发现有2个不同的Queue,绑定了studyExchange
4、访问地址:http://localhost:8801/sendMessage,发送消息
发现消息消费者(8802|8803)2个节点,都收到同一条消息,并进行了处理
说明:出现消息被同一种服务重复消费的问题
同一消息被同一服务分组消费
1、在消息消费者(8802|8803)2个节点的配置文件中配置组属性
1 spring.cloud.stream.bindings.input.group = testA
2、重新相关项目
3、查看RabbitMQ的Web后台,发现只有一个studyExchange.testA的Queue,
且studyExchange.testA绑定了studyExchange,里面有2个Chanal
4、访问地址:http://localhost:8801/sendMessage,发送消息
发现一条消息只会被1个消费者,获取并消费。
发送多条消息,消息有消费者轮询的方式消费
Spring Cloud Stream消息持久化
消费者设置分组后
1、关闭消费者服务
2、查看RabbitMQ的Web后台,发现studyExchange.testA的Queue,并没有被删除
3、访问地址:http://localhost:8801/sendMessage,发送消息,
发现消息继续发送到了studyExchange.testA中
4、启动消费者服务,发现消费者服务能够消费到,服务未启动时提供者发送的消息
说明已到到消息持久化的效果
注:消费者未设置分组时,关闭消费者服务,对应的queue会理解被删除,那么提供者也就无法方队列中发送消息了