文章目录
前言
今天大致学完了Stream
一、概览
1、起因
现在有许多常用的MQ(消息中间件)
- ActiveMQ
- RabbitMQ
- RocketMQ
- Kafka
多种不同的MQ之间的交互较难,且难以临时掌握某种MQ,因此Cloud Stream诞生了。
Cloud Stream可以屏蔽底层消息中间件的差异,不需要关注具体MQ的细节,只需要用一种适配锁定的方式,自动在各种MQ内切换,降低切换成本,是一种统一消息的编程模型
2、结果
官方定义Spring Cloud Stream是一个构建消息驱动微服务的框架。
应用程序通过inputs或者 outputs 来与Spring Cloud Stream中binder对象交互。
通过我们配置来binding(绑定),而Spring Cloud Stream 的binder对象负责与消息中间件交互。所以,我们只需要搞清楚如何与Spring Cloud Stream交互就可以方便使用消息驱动的方式。
通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。
Spring Cloud Stream为一些供应商的消息中间件产品提供了个性化的自动化配置实现
引用了发布-订阅、消费组、分区的三个核心概念。
目前仅支持RabbitMQ、 Kafka。
3、设计思想
标准MQ
- 生产者/消费者之间靠消息媒介传递信息内容
- 消息必须走特定的通道 - 消息通道 Message Channel
- 消息通道里的消息如何被消费呢,谁负责收发处理
- 消息通道MessageChannel的子接口SubscribableChannel,由MessageHandler消息处理器所订阅。
Cloud Stream的作用
RabbitMQ和Kafka这两个消息中间件在架构上存在不同
- RabbitMQ有exchange
- Kafka有Topic和Partitions分区
消息中间件的差异性导致我们实际项目开发给我们造成了一定的困扰
我们如果用了两个消息队列的其中一种,后面的业务需求,我想往另外一种消息队列进行迁移,这时候无疑就是一个灾难性的,一大堆东西都要重新推倒重新做,因为它跟我们的系统耦合了
这时候Spring Cloud Stream给我们提供了—种解耦合的方式。
Cloud Stream统一底层差异
在没有绑定器这个概念的情况下,我们的SpringBoot应用要直接与消息中间件进行信息交互的时候
由于各消息中间件构建的初衷不同,它们的实现细节上会有较大的差异性
通过定义绑定器作为中间层,完美地实现了应用程序与消息中间件细节之间的隔离
通过向应用程序暴露统一的Channel通道,使得应用程序不需要再考虑各种不同的消息中间件实现
Binder
- INPUT对应消费者
- OUTPUT对应生产者
Stream中的消息通信方式遵循了发布-订阅模式
Topic主题进行广播
- 在RabbitMQ就是Exchange
- 在Kafka就是Topic
4、常用注解
- Binder
- 连接中间件,屏蔽差异
- Channel
- 通道,是队列Queue的一种抽象,在消息通讯系统中就是实现存储和转发的媒介,通过Channel对队列进行配置
- Source和Sink
- 简单的可理解为参照对象是Spring Cloud Stream自身,从Stream发布消息就是输出,接受消息就是输入
组成 | 说明 |
---|---|
Middleware | 中间件,目前只支持RabbitMQ和Kafka |
Binder | Binder是应用与消息中间件之间的封装,目前实行了Kafka和RabbitMQ的Binder,通过Binder可以很方便的连接中间件,可以动态的改变消息类型(对应于Kafka的topic,RabbitMQ的exchange),这些都可以通过配置文件来实现 |
@Input | 注解标识输入通道,通过该输乎通道接收到的消息进入应用程序 |
@Output | 注解标识输出通道,发布的消息将通过该通道离开应用程序 |
@StreamListener | 监听队列,用于消费者的队列的消息接收 |
@EnableBinding | 指信道channel和exchange绑定在一起 |
二、使用步骤
1、引入库
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>
2、application.yml
消息生产者的yml
server:
port: 8801
spring:
application:
name: cloud-stream-provider
cloud:
stream:
binders: # 在此处配置要绑定的rabbitmq的服务信息;
defaultRabbit: # 表示定义的名称,用于于binding整合
type: rabbit # 消息组件类型
environment: # 设置rabbitmq的相关的环境配置
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
bindings: # 服务的整合处理
output: # 这个名字是一个通道的名称
destination: studyExchange # 表示要使用的Exchange名称定义
content-type: application/json # 设置消息类型,本次为json,文本则设置“text/plain”
default-binder: defaultRabbit # 设置要绑定的消息服务的具体设置
eureka:
client: # 客户端进行Eureka注册的配置
service-url:
defaultZone: http://localhost:7001/eureka
instance:
lease-renewal-interval-in-seconds: 2 # 设置心跳的时间间隔(默认是30秒)
lease-expiration-duration-in-seconds: 5 # 如果现在超过了5秒的间隔(默认是90秒)
instance-id: send-8801.com # 在信息列表时显示主机名称
prefer-ip-address: true # 访问的路径变为IP地址
消息消费者的yml
server:
port: 8802
spring:
application:
name: cloud-stream-consumer
cloud:
stream:
binders: # 在此处配置要绑定的rabbitmq的服务信息;
defaultRabbit: # 表示定义的名称,用于于binding整合
type: rabbit # 消息组件类型
environment: # 设置rabbitmq的相关的环境配置
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
bindings: # 服务的整合处理
input: # 这个名字是一个通道的名称
destination: studyExchange # 表示要使用的Exchange名称定义
content-type: application/json # 设置消息类型,本次为对象json,如果是文本则设置“text/plain”
default-binder: defaultRabbit # 设置要绑定的消息服务的具体设置
#分组,默认组名为随机序列号
group: sakanalA
eureka:
client: # 客户端进行Eureka注册的配置
service-url:
defaultZone: http://localhost:7001/eureka
instance:
lease-renewal-interval-in-seconds: 2 # 设置心跳的时间间隔(默认是30秒)
lease-expiration-duration-in-seconds: 5 # 如果现在超过了5秒的间隔(默认是90秒)
instance-id: receive-8802.com # 在信息列表时显示主机名称
prefer-ip-address: true # 访问的路径变为IP地址
3、主启动类
消息生产者
@SpringBootApplication
public class StreamMQMain8801 {
public static void main(String[] args) {
SpringApplication.run(StreamMQMain8801.class, args);
}
}
消息消费者
@SpringBootApplication
public class StreamMQMain8802 {
public static void main(String[] args) {
SpringApplication.run(StreamMQMain8802.class, args);
}
}
4、业务类
消息生产者
public interface IMessageProvider {
public String send();
}
@EnableBinding(Source.class) //定义消息的推送管道
public class IMessageProviderImpl implements IMessageProvider {
@Resource
private MessageChannel output; // 消息发送管道
@Override
public String send() {
String serial = UUID.randomUUID().toString();
output.send(MessageBuilder.withPayload(serial).build());
System.out.println("*****serial: "+serial);
return null;
}
}
消息消费者
@EnableBinding(Sink.class)
public class ReceiveMessageListenerController {
@Value("${server.port}")
private String serverPort;
@StreamListener(Sink.INPUT)
public void input(Message<String> message)
{
System.out.println("消费者1号,----->接受到的消息: "+message.getPayload()+"\t port: "+serverPort);
}
}
5、Controller
消息生产者
@RestController
public class SendMessageController {
@Resource
private IMessageProvider iMessageProvider;
@GetMapping("/sendMessage")
public String sendMessage(){
return iMessageProvider.send();
}
}
- 启动RabbitMQ
- 启动服务注册中心-7001
- 启动消息生产者-8801
- 启动消息消费者-8802
- 启动消息消费者-8803
http://localhost:8801/sendMessage
:消息生产者生产消息- 在8802和8803的控制台都可以看到消息已被接收
三、扩展
1、消息重复消费
消息消费者-8802-8803,都可以接收到消息生产者8801发出的消息,若8802-8803的作用一致,可能会浪费资源或造成数据错误等
比如为订单系统做集群部署,作用相同的8802-8803都会从RabbitMQ中获取到订单信息,如果同一个订单同时被两个服务获取到,那么就会造成数据错误。
为避免这种情况,可以使用Stream中的消息分组来解决
在Stream中处于同一个group中的多个消费者是竞争关系,就能够保证消息只会被其中一个应用消费一次
不同组是可以全面消费的(重复消费)。
消息消费者yml
server:
port: 8802
spring:
application:
name: cloud-stream-consumer
cloud:
stream:
binders: # 在此处配置要绑定的rabbitmq的服务信息;
defaultRabbit: # 表示定义的名称,用于于binding整合
type: rabbit # 消息组件类型
environment: # 设置rabbitmq的相关的环境配置
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
bindings: # 服务的整合处理
input: # 这个名字是一个通道的名称
destination: studyExchange # 表示要使用的Exchange名称定义
content-type: application/json # 设置消息类型,本次为对象json,如果是文本则设置“text/plain”
default-binder: defaultRabbit # 设置要绑定的消息服务的具体设置
#为该服务分为A_group组
#默认为随机序列组,所以如果没有显式确定某一组,每一个服务都是独立的一组
#如果组名相同,表名是同一组
group: A_group
对于相同组,会采用轮询分组,同一组每次自会有一个消费者
8801服务发送的消息只能被同一组内的8802-8803其中一个接收到,避免了重复消费
2、消息持久化
- 先停止消息消费者8802-8803
- 8802/8803需要先启动,且至少要有一个服务表明分组,这样会将分组名暂时保存再RabbitMQ中
- 如果没有显式指定分组,服务的组名取值随机,且不会保存再RabbitMQ中
- 去除8802的分组
group: A_group
,8803的分组保存group: A_group
- 消息生产者8801先发送多条消息到RabbitMQ中
- 再启动8802(没有显式指定分组名),后台没有打印消息,该服务未获取消息。
- 再启动8803(显式指明了分组名),后台打印出消息,该服务获取到了消息。(消息持久化体现)
如果消息消费者出故障下线,之后重新上线:
- 没有指明分组的服务不会从RabbitMQ中获取到下线到上线期间的任何消息
- 没有指明分组的服务也存在组名,其中为随机序列,组名不会保存在RabbitMQ中
- 在线期间这个随机组名存在,但是一旦服务下线,组名立即消除,之后发送的消息不会保存在该消息通道中
- 就算会保存消息,下次上线时的组名不一致,也获取不到消息
- 已经指明分组的服务可以从RabbitMQ中获取到下线到上线期间的消息
- 组名会保存在RabbitMQ中,在服务上线后,会立即从RabbitMQ中获取到该组名中暂时保存的消息