springcloud微服务-stream

消息驱动模型

 

消息驱动的应用场景

1.跨系用异步通信

2.应用解耦

3.流量削峰 

 

stream体系架构

1.input 用于将消息传递给消费者进行消费

2.output 用于将生产者的新消息发送到对应的topic中

3.binder 抽象层，作为连接外部mq中间件的桥梁

 

 

发布订阅模式（广播）demo工程：

1.创建mytopic接口，定义input和output

 

 

 2.将input和out在配置文件中绑定在一个topic中

 

 3.生产消息

 

 4.消费消息

 

 

实际工作中mq的应用场景是什么？

主商品id+门店id->渠道商品id

商品主属性变更->id变动->原缓存中的渠道商品id变成了无用的脏数据->清空缓存->mq广播组清除服务节点本地缓存->mq单播组清除redis缓存

 

单播模式（单组内单个消费+负载均衡）demo工程：

1.创建groupTopic

 

 2.创建producer

 

 3.创建consumer，注意要在@enableBindings注解里面添加grouptopic类

 

 

 

 4.配置文件定义绑定关系和定义消费组

 

 5.配置文件定义消费分区

展示不全的部分：

 

消费分区和消费组的区别

1.消费组针对消费者，不同消费组之间是广播关系，同一个消费组内是负载均衡关系

2.消费分区针对生产者和消费者，生产者将消息分区发送（partition），消费者根据spel表达式订阅相应的分区，只有下标满足表达式的组才能消费到消息

3.消费组和消费分区之间是一种协作关系

 

 

延迟队列demo

1.创建delayedTopic

 

 2.创建producer，多了一个setHeader的步骤

 

 3.创建consumer

　　

 

 4.配置文件添加配置，核心是第三个配置

 

 

stream异常处理策略

1.重试

　　1）consumer重试，在重试期间不会抛出异常

　　2）re-queue重回队列

 

 

 

2.降级

　　1）创建producer和consumer

　　

 

 

 

 

 

　　 

 

 

 　　2）更改配置文件

　　 

 

 

 

 

 　　3）添加降级方法，注意信道名称

　　

 

 

3.人工处理

　　1）死信队列

 

 

 　　　黄色是正常队列，黑色是死信队列，只有具备DLX（死信交换机）和DLK（死信路由key）特征的正常队列才具备将消息转发到死信队列的能力

　　死信队列使用步骤：

　　　　1）开启插件

　　

　　　　2)创建producer和consumer，配置死信队列

　　　　

可以在控制台将死信队列中的消息重回正常队列进行再次消费（需要安装第一步中提到的插件）