本章介绍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会理解被删除，那么提供者也就无法方队列中发送消息了
