1、概述

什么是MQ

消息队列

流量削峰

应用解耦：上游只需发送消息

异步处理：异步处理回调消息

四大核心概念

生产者、交换机、队列、消费者

六大核心模式

简单、工作队列、发布订阅、路由、主题、发布确认

image-20220125223147422

工作原理

Broker

Virtual host

Connection

Channel

Exchange

Queue

Binding

image-20220125223250580

2、核心

工作队列

轮询分发消息

消息应答：消费者是否处理消息

自动应答、手动应答（批量应答）

消息自动重新入队

rabbitmq持久化：队列持久化、消息持久化

不公平分发

预取值：通道中堆积消息个数

发布确认

单个确认发布

批量确认发布

异步确认发布：异步通知——交换机确认收到、未确认收到

并发链路式队列——发消息和监听线程之间传递消息——本质：map

1、发送消息时进记录队列

2、确认回调再删除

未删除的——未确认消息

跳表

image-20220125224155047

image-20220125224048175

Exchange

直接(direct), 主题(topic) ,标题(headers) , 扇出(fanout)

无名 exchange

临时队列

bindings

Fanout

广播：路由key为空

image-20220125224517818

Direct

发送路由key对应队列——无论队列个数

image-20220125224644373

Topics

没有*和#：fanout、direct模式

*(星号)可以代替一个单词

#(井号)可以替代零个或多个单词

3、高级

死信队列

发送异常消息——进入死信队列

死信队列的来源：

消息 TTL 过期

队列达到最大长度(队列满了，无法再添加数据到 mq 中)

消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false.

image-20220125224938734

延迟队列

延时队列

延迟队列——消息过期进入死信队列

存放需要在指定时间被处理的元素的队列

应用场景

image-20220125225016545

缺陷：ttl不灵活

延时队列优化

QC队列不设置过期时间，由生产者设置ttl

缺陷：队列FIFO

基于插件优化

基于插件的交换机：在交换机处延迟

延迟交换机：类型、延迟类型（直接：路由key固定）

image-20220125225256329

其他延时队列：

Java 的 DelayQueue，利用 Redis 的 zset，利用 Quartz，或者利用 kafka 的时间轮。RabbitMQ安全，完善。

发布确认高级

交换机回调

交换机确认消息是否收到

写回调方法、注入

image-20220125225816018

生产者只管给交换机消息，只接受交换机的接收结果

路由错误无法接收结果

回退消息

无法路由时，消息回退给交换机，通知生产者

备份交换机

无法投递的消息给备份交换机

没有什么是加一层解决不了的

image-20220125230021103

备份优先级更高

幂等性

幂等性：重复提交

消费者ack中断，造成重新消费

解决思路：生成全局唯一id，消费之前判断是否被消费过

1、唯一ID + 指纹码机制（数据库）

2、Redis原子性：利用 redis 执行 setnx 命令，天然具有幂等性。从而实现不重复消费

优先级队列

设置优先级参数

惰性队列

消息存到磁盘中，消费者从磁盘取

内存占比非常小，取消息慢

4、集群

普通集群

image-20220125221757500

镜像集群

image-20220125222245390

高负载均衡

nginx、gateway、Haproxy等集群，进行反向代理

image-20220125230327710

以下暂用不到

Shovel集群

远程同步

Federation 联邦集群

Federation Exchange、Federation Queue

img