one
异步、解耦、削峰
two
深入理解核心编程模型及消息应用场景
主要通过多了QUEUE进行交换消息
虚拟机的消息是不能发到另外虚拟机的Queue上的
- 生产者创建connection建立连接
- 通过connection声明channel信道
- 通过channel声明队列
- 声明好队列后发送消息
- 消费者拿到connection
- 打开信道channel
- channel声明队列
- channel拿到消息进行交互
细节
connection可以创建多个channel
声明交换机和队列
声明Stream类型的对列
对列类型的区别:
classic:先进先出
quorum:在classic上增加了消息的可用性【集群中写过超过半数的队列,这消息才算正常写完】
stream:用文本的形式把消息暂存起来
交换机和队列的绑定
channel.exchangeBing()
发送消息
channel.basicPublish()
消费者主动拿消息
不知道消息什么时候来,会不及时不建议使用
消费者被动拿消息
推消息
只要mq收到消息,就会主动向消费端推送消息
1
2 work queue
分发到消费者,只能消费一次
自动应答,收到就减队列消息。存在拿到消息没有落地到数据库导致消息丢失
手动应答
3 发布订阅模式
4 direct
5 topics
6 headers
交换机的header的
7 publish confirms
可靠消息发送
springboot集成
- 引入依赖
- 配置参数
- 声明
- 使用RabbitmqTemplate对象发送消息
=================================================================================
系统study
名词介绍
:
Broker:接收和分发消息的应用
生产者
消费者
connection:有多个channel
channel:在connection中,且channel之间互相隔离
exchange
queue
安装
先安装环境erlang
安装依赖包
安装rabbit server
启动服务
安装服务界面【需要关闭server】
安装后关闭防火墙,即可打开
创建环境
生产者代码
通过连接工厂创建连接connection
需要地址
需要用户名
需要密码
通过连接获取信道
生成队列
队列名称
是否持久化
是否共享
是否自动删除
其他参数【延迟、死信】
发消息的内容
信道来发消息
发送到哪个交换机
路由key值,
其他参数信息
发送消息的消息体
消费者代码
队列名称
创建工厂连接
创建连接
创建信道【接收消息】
消费
消费哪个对列
是否自动应答
消费者未消费成功的回调
消费者取消消费回调
其中第三第四参数的函数式接不能直接往里面填,需要实例化
work Queues
相比hello world,是大量消息,被多个消费者消费。消费者之间是竞争关系
封装连接生成信道的工具类,今后直接调用生成信道
写消费者代码
消息的接受
声明队列
写第二个消费
通过IDEA工具进行设置,可以再次开启消费者服务
生产者代码实现【发送大量消息】
指定队列名称public static final String queue_name="hello"
发送大量的消息
声明队列
消息应答
mq将消息删除应该在消费者应答之后进行删除
自动应答
适用于大数据量
手动应答【有分两种】
一种是多了个是否批量处理的参数
消息的自动重新入队
手动应答代码
消费者02
队列持久化
消息持久化
消费者端
不公平分发
发生在消费端
消费者在接收消息前设置 不公平分发
预取值
发布确认
帮我们保证消息不丢失的重要环节
在确保消息的持久化【保存磁盘】过程中会出现消息的丢失
需要队列持久化
队列的消息必须持久化
保存到磁盘上【保存磁盘上也可能出现丢失 所以需要发布确认】,经过方法确认后,才能肯定消息不会丢失
这里实现发布确认
有三种模式
单个发布确认
批量确认
异步确认发布
发消息前得先准备监听器
如何处理异步未处理消息
发送消息时候记录消息
在确认消息删除确认的消息
在未确认消息里做消息处理【保存,重新发送……】
交换机
绑定
发布订阅【fanout】
生产者
直接交换机
key 不相同
死信队列
死信来源
TTL过期
队列超长
消息被拒
架构图
死信实战
消费者
普通队列的消息成为死信后转发至死信交换机中,需要用到参数
绑定
生产者
消费者2【消费死信】
超过长度成为死信
消息被拒
延迟队列【死信队列的一种TTL】*******************************************************************************重要
基于死信队列
编写TTL流程代码。
整合springboot前,我们队列,交换机等都在消费端申请;整合后问我们直接可以在项目的配置类中写即可
配置文件类代码
绑定
生产者
消费者
存在问题
绑定
测试
MQ插件实现延迟队列【就是后面发的消息会等前面发完才发即使时间很短】
重启
原来的实现,基于队列实现
基于交换机实现
基于插件实现的代码
配置文件类代码【交换机、队列、和之间的绑定】
申明交换机类型一定要延迟类型
申明交换机
申明队列
之间的绑定
生产者
消费者
重复下
结果
发布确认高级
代码编写【三步:配置类、生产、消费】
生产者
消费者
回调接口【消息发送失败,进行回调】,生产者发给交换机,感知是否收到【没有确认或确认失败都认为失败】
交换机收到消息、没收到消息都会调取这个接口。收不到返回值会是false反之就是true,后面参数代表原因,前面参数代表发送内容
在配置文件中加配置
队列出现问题,直接丢弃。设置Mandatory参数
备份交换机
备份交换机改为如下:
绑定
确认交换机转发到备份交换机
消费者