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,配置死信队列
可以在控制台将死信队列中的消息重回正常队列进行再次消费(需要安装第一步中提到的插件)