SpringCloud Stream消息驱动之分组消费与持久化

所有代码都在github上：https://github.com/demonruin/cloud2020/tree/master

 

为了演示分组消费和持久化，现在clone一份消息驱动消费者consumer8003，是基于consumer8802来clone的，只需要该端口号等信息即可。等consumer8803构建完毕后，启动如下项目：

RabbitMQ、eureka7001、provider8801、consumer8802、comsumer8803

当预备环境准备完毕后，请求provier8801的生产信息接口http://localhost:8801/sendMsg,会产生消息，但是8802和8803消费者都会接收到消息。而消息都一样~！

重复消费：

比如在如下场景中，订单系统我们做集群部署,都会从RabbitMQ中获取订单信息,那如果一个订单同时被两个服务获取到，那么就会造成数据错误,我们得避免这种情况。这时我们就可以使用Stream中的消息分组来解决

 

 

注意在Stream中处于同一个group中的多个消费者是竞争关系,就能够保证消息只会被其中一个应用消费一次。

不同组是可以全面消费的(重复消费)，

同一组内会发生竞争关系，只有其中一个可以消费

微服务应用放置于同一个group中，就能够保证消息只会被其中一一个应用消费一次。不同的组是可以消费的，同一一个组内会发生竞争关系，只有其中一一个可以消费。

现在回过头来看咱们的服务，怎么可以查看到两个消费者是不是在同一个组呢，可以通过RabbitMQ的web端查看

在这里面，我们可以看到Queues里面有两个分组，都是以studyExchange来开头的，所以我们可以理解为这就是8802和8803的两个分组，因为不在同一组，所以会重复消费消息，所以，为了防止重复消费消息，我们需要将8802和8803设置成同一个组。

故障现象：重复消费 

故障原因：默认分组group是不同的，组流水号不一样，被认为是不同组，可以重复消费

解决方法：自定义分配置分组，自定义配置分为同一个组，即可解决重复消费问题

设置8802和8803的分组信息，需要修改appllication.yml的配置，在bindings下面添加group：自定义分组名称   分组信息即可

spring:
  application:
    name: cloud-stream-rabbitmq-consumer
  cloud:
    stream:
      binders: # 在此处配置要绑定的rabbitmq的服务信息；
        defaultRabbit: # 表示定义的名称，用于于binding整合
          type: rabbit # 消息组件类型
          environment: # 设置rabbitmq的相关的环境配置
            spring:
              rabbitmq:
                host: localhost
                port: 5672
                username: admin
                password: admin
                virtual_host: my_vhost
      bindings: # 服务的整合处理
        input: # 这个名字是一个通道的名称
          destination: studyExchange # 表示要使用的Exchange名称定义
          content-type: application/json # 设置消息类型，本次为json，文本则设置“text/plain”
          binder: defaultRabbit # 设置要绑定的消息服务的具体设置
          group: kingA #设置分组

此时provider8801产生消息，而后8802和8803都只能竞争消费信息了

分布式微服务应用为了实现高可用和负载均衡,实际上都会部署多个实例，本例启动了两个消费微服务(8802/8803)，多数情况，生产者发送消息给某个具体微服务时只希望被消费一次, 按照上面我们启动两个应用的例子，虽然它们同属一个应用,但是这个消息出现了被重复消费两次的情况。为了解决这个问题，在Spring Cloud Stream中提供了消费组的概念。

这样就解决了 重复消费的问题，实现了分组消费！

 

持久化：

上面我们解决了重复消费问题，现在我们进行一次持久化演示~

1、先去掉8802的group配置，然后8803保留group：kingA配置信息，然后关闭8802和8803微服务。

2、此时请求8801provider，产生几条消息

3、然后启动8802消费者，控制台并没有打印出接收到的消息

4、然后启动8803消费者，因为保留了group分组配置信息，所以启动后会去主动拉取消息进行消费，能接收步骤2产生的所有消息

上述截图表示 8801产生了四条消息，而8802没有接收消费消息，8803接收了全部消息进行了消费

所以8803消息持久化了~