RabbitMQ概念及知识点

使用场景

• 异步处理
• 应用解耦
• 流量控制(削峰)

工作流程

• 生产者连接RabbitMQ，建立TCP连接( Connection)，开启信道(Channel)
• 生产者声明一个Exchange(交换器)，并设置相关属性，比如交换器类型、是否持久化等
• 生产者声明一个队列井设置相关属性，比如是否排他、是否持久化、是否自动删除等
• 生产者通过 bindingKey (绑定Key)将交换器和队列绑定( binding )起来
• 生产者发送消息至RabbitMQ Broker，其中包含 routingKey (路由键)、交换器等信息
• 相应的交换器根据接收到的 routingKey 查找相匹配的队列。
• 如果找到，则将从生产者发送过来的消息存入相应的队列中。
• 如果没有找到，则根据生产者配置的属性选择丢弃还是回退给生产者
• 关闭信道。
• 关闭连接。

用docker创建实例

docker run -d --name rabbitmq --publish 5671:5671 \
--publish 5672:5672 --publish 4369:4369 --publish 25672:25672 --publish 15671:15671 --publish 15672:15672 \
rabbitmq:management

4369,25672 -- erlang发现和集群端口
5672,5671 --AMQP端口
15672 -- 管理界面ui端口

接听注解

• @RabbitListener：类+方法上（监听哪些队列）
• @RabbitHandler：标在方法上（重载区分不同的消息）

消息确认机制-----可靠抵达

• 想要保证消息不丢失，可靠抵达，可以使用事务消息，但是性能下降250倍。为此引入确认机制
• 生产者–>Broker：confirmCallback：确认模式
• Exchange–>Queue：returnCallback：未投递到queue退回模式
• Queue–>消费者：ack机制

RabbitMQ延时队列（实现定时任务）

• 场景：未付款的订单，超过一定时间后，系统自动取消订单并释放占有物品
• 常用解决方案：spring的schedule定时任务轮询数据库
• 缺点：消耗系统内存，增加了数据库的压力，存在较大的时间误差
• 解决方法：rabbitMQ的消息TTL和死信Exchange结合