上述的问题就是消息的 重复消费 问题，那么这个问题为什么如此重要呢？其实重复消费这个问题本身不可怕，可怕的是没考虑到重复消费之后，怎么保证幂等性。（幂等性 通俗的说，就一个数据，或者一个请求，重复很多次，需要确保对应的数据是不会改变的，不能出错）。分布式微服务应用为了实现高可用和负载均衡，实际上同一功能的服务都会部署多个具体的服务实例。举个例子，假设有一个系统，有一条消息要求往数据库里插入一条数据，要是这个消息重复消费两次，结果就是向数据库里插入了两条数据，这样数据就错了，就违背了幂等性原则，但是要是该消息消费到第二次的时候，可以判断一下已经消费过了，然后直接将该消息丢弃，这就实现了只插入一条数据，一条消息重复出现了两次，但是只有第一次真正被消费了，数据库里也就只插入了一条数据，这就保证了系统的幂等性。
上面简单的介绍了消息的重复消费问题，那如何解决这种重复消费问题呢，那就需要我们进行 分组和持久化属性组 操作，利用SpringCloud Stream中的消息分组来解决这个问题，需要注意的是在Stream中处于同一组中的多个消息消费者是竞争关系，也就是保证生产者所发送的同一个消息只会被其中一个消费者消费一次。 不同组的消费者是可以对消息进行全面消费（重复消费）的，只有同一组内才会发生竞争关系。
在RabbitMQ中，默认分组group是不同的，组流水号不一样，被认为不同组，我们查看testExchange交换机，可以发现8802和8803两个消息消费者处于不同的组，所以8801消息生产者发送的消息可以被这两个消费者重复消费：
上面在RabbitMQ控制面板中我们看到的组流水号是系统随机分配的，这样无疑不好控制，所以我们应该自定义配置分组，将8802/8803两个消息消费者微服务分为同一个组，以此来解决消息的重复消费问题。
先来演示如何自定义分组
在8802/8803微服务中的配置文件中分别添加组名属性：
spring: cloud: stream: bindings: input: group: A/B # 分组名称这里我们将8802设置为A组，8803设置为B组，然后我们将消息消费方的两个微服务重启，我们再次查看其组流水号，发现不再是长长的随机组流水号，而变成了我们自定义的分组：
此时由于8802/8803位于两个不同分组下，所以没有竞争关系，消息生产者发送消息后，仍然可以重复消费。
下面我们将这两个消息消费方微服务分到相同的消费组中，这样每次就只有一个消费者，消息生产者发送的消息只能被8802或8803其中一个接受到，这样就避免了重复消费，将8802和8803的分组名都改为A，再次重启两个消息消费方微服务，此时我们可以看到在分组A下已经有了两个消费者。
再用生产者发送5条消息，我们发现8802/8803分别消费了3条和2条不同的消息，而没有出现重复消费的问题。
3.3 持久化通过上述，解决了重复消费问题，再来看看持久化
加上了group就自动支持持久化了
下面来演示一下持久化
停止8802/8803并去除掉8802分组group：A（8803的分组group A没有去掉）
8801发送4条消息到rabbitmq
先启动8802（无分组属性配置），后台没有打出来消息（消息丢失故障）
再启动8803（有分组属性配置），后台打出了4条消息（消费持久化消息）