Stream 分组消费与持久化
新建了一个module cloud-stream-rabbitmq-consumer8803，作为消息接收模块（参考8802）
这一块是根据新建的这个进行的演示：
现在就是这样的架构：
比如在如下场景中，订单系统我们做集群部署，都会从RabbitMQ中获取订单信息，那如果一个订单同时被两个服务获取到，那么就会造成数据错误，我们得避免这种情况，这时我们就可以使用Stream中的消息分组来解决。
注意在Stream中处于同一个group中的多个消费者是竞争关系，就能够保证消息只会被其中一个应用消费一次。
不同组是可以全面消费的（重复消费），同一组内会发送竞争关系，只有其中一个可以消费。
目前遇到的问题：
目前是8802/8803同时都收到消息了，存在重复消费问题。
分组：
原理：
微服务应用放置在同一个group中，就能够保证消息只会被其中一个应用消费一次。
不同的组是可以消费的，同一个组内会发生竞争关系，只有其中一个可以消费。
把8802/8803都变成不同组，group两个不同
修改8802/8803的yml配置文件
结论：还是重复消费。
分布式微服务应用为了实现高可用和负载均衡，实际上都会部署多个实例，本次启动了两个消费微服务8802/8803
多数情况下，生产者发送消息给某一个具体的微服务时只希望被消费一次，按照上面我们启动两个应用的例子，虽然他们同属一个应用。
但是这个消费出现了被重复消费两次的情况，为了解决这个问题，在spring cloud Stream中提供了消费组的概念。
怎么实现这一消费组：
8802/8803实现了轮询分组，每一次只有一个消费者
8801模块发送的消息只能被8802或者8803其中一个接受到，这样避免了重复消费。
8802/8803都变成相同组，group两个相同。
怎么设置？
在8802和8803消费者上面设置一样的分组group
结论：
这样8802和8803消费者上面分别收到了一个消息，这样就避免了重复消费的问题。
同一个组会竞争资源，轮询。不同组会重复消费。
持久化
关于自定义分组
**场景：**停止8802/8803并且去除掉8802的分组group:atguiguA
注意：8803的分组没有去掉。
结果：
如果8802去掉分组，而8803不去掉，当8802/8803都关闭服务，8801这时候发送消息，8802再启动的时候不会重新获得未曾获得的消息并消费，而8803重启后会获得8801之前发送的消息并消费。
所以group分组属性在消息重复消费和消息持久化消费 避免消息丢失是非常重要的属性
就是默认的分组不会保留未曾获得的消息，自定义的分组会保留。