springcloud入门——stream

目录

1.初识Stream

2.Stream编码常用注解简介

 3.stream案例

---

1.初识Stream

Stream为什么被引入：

常见的MQ(消息中间件)：ActiveMQ、RabbitMQ、RocketMQ、Kafka

• 生产者/消费者之间靠消息媒介传递信息内容
• 消息必须走特定的通道 - 消息通道 Message Channel
• 消息通道里的消息如何被消费呢，谁负责收发处理 - 消息通道MessageChannel的子接口SubscribableChannel，由MessageHandler消息处理器所订阅。

我们的同一个平台之间，比如后端java和大数据平台之间，可能使用的是不同类型的中间件，则这就给一个系统造成一些切换、维护、开发的困难。所以有没有一种新的技术诞生，让我们不再关注具体MQ的细节，我们只需要用一种适配绑定的方式，自动的给我们在各种MQ内切换就变得很重要了。（类似于Hibernate）

Cloud Stream就是一个屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型。

Cloud Stream设计理念：

在没有绑定器这个概念的情况下，我们的SpringBoot应用要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性。通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件细节之间的隔离。通过向应用程序暴露统一的Channel通道，使得应用程序不需要再考虑各种不同的消息中间件实现。

应用程序通过inputs 或者outputs 来与Spring Cloud Stream中binder对象交互。通过我们配置来binding(绑定)，而Spring Cloud Stream 的binder对象负责与消息中间件交互。所以，我们只需要搞清楚如何与Spring Cloud Stream交互就可以方便使用消息驱动的方式。

（通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。）

Binder：

    INPUT对应于消费者

    OUTPUT对应于生产者

Stream中的消息通信方式遵循了发布-订阅模式

Topic主题进行广播

• 在RabbitMQ就是Exchange
• 在Kakfa中就是Topic

Stream目前仅支持RabbitMQ、 Kafka。

2.Stream编码常用注解简介

Spring Cloud Stream标准流程套路：

• Binder - 很方便的连接中间件，屏蔽差异。
• Channel - 通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置。
• Source和Sink - 简单的可理解为参照对象是Spring Cloud Stream自身，从Stream发布消息就是输出，接受消息就是输入。

常用注解：

 3.stream案例

工程中新建三个子模块：

• cloud-stream-rabbitmq-provider8801，作为生产者进行发消息模块
• cloud-stream-rabbitmq-consumer8802，作为消息接收模块
• cloud-stream-rabbitmq-consumer8803，作为消息接收模块

修改pom文件，导入rabbit依赖。

1.cloud-stream-rabbitmq-provider8801编写：

编写yml文件，启用rabbitmq，并设置binder属性：

此处为测试成功后，rabbitmq显示的Exchange topic：

编写业务类（接口及实现类）：

此处注意导入的包。

编写控制类：

测试：

    访问 - http://localhost:8801/sendMessage，后台结果如下：

2.cloud-stream-rabbitmq-consumer8802编写

编写yml文件，大体相同，区别如下：

编写控制类：

启动主启动类，进行测试：

8801发送8802接收消息

rabbitmq出现波动：

3.cloud-stream-rabbitmq-consumer8803编写

依照8802，克隆出来一份运行8803 - cloud-stream-rabbitmq-consumer8803。

运行后有两个问题

1. 有重复消费问题
2. 消息持久化问题

• 目前是8802/8803同时都收到了，存在重复消费问题

生产实际案例

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

注意在Stream中处于同一个group中的多个消费者是竞争关系，就能够保证消息只会被其中一个应用消费一次。不同组是可以全面消费的(重复消费)。

微服务应用放置于同一个group中，就能够保证消息只会被其中一个应用消费一次。

不同的组是可以重复消费的，同一个组内会发生竞争关系，只有其中一个可以消费。

修改yml文件，8802/8803都变成不同组，group两个不同：

结论：还是重复消费（与默认情况下，两者不同组情况相同）

8802/8803实现了轮询分组，每次只有一个消费者，8801模块的发的消息只能被8802或8803其中一个接收到，这样避免了重复消费。

8802/8803都变成相同组，group两个相同

结论：同一个组的多个微服务实例，每次只会有一个拿到

停止8802/8803并去除掉8802的分组group:sevenA，8803的分组group: sevenA没有去掉。

8801先发送4条消息到RabbitMq。

先启动8802，无分组属性配置，后台没有打出来消息。

再启动8803，有分组属性配置，后台打出来了MQ上的消息。(消息持久化体现)