RabbitMq知识概述

本文来说下RabbitMq相关的知识与概念

文章目录

概述
- AMQP协议
- Exchange
消息如何保证100％投递
- 什么是生产端的可靠性投递
- 可靠性投递保障方案
消息幂等性
高并发的情况下如何避免消息重复消费
- confirm 确认消息、Return返回消息
- 如何实现confirm确认消息
- return消息机制
消费端自定义监听
- 消费端限流
- 消费端ack与重回队列
- 消息重回队列
- TTL队列/消息
死信队列
rabbitMQ集群模式
- 主备模式
- 集群模式
- 多活模式
本文小结

概述

RabbitMQ是基于AMQP协议的，通过使用通用协议就可以做到在不同语言之间传递

在这里插入图片描述

AMQP协议

核心概念

server：又称broker，接受客户端连接，实现AMQP实体服务。
connection：连接和具体broker网络连接。
channel：网络信道，几乎所有操作都在channel中进行，channel是消息读写的通道。客户端可以建立多个channel，每个channel表示一个会话任务。
message：消息，服务器和应用程序之间传递的数据，由properties和body组成。properties可以对消息进行修饰，比如消息的优先级，延迟等高级特性；body是消息实体内容。
Virtual host：虚拟主机，用于逻辑隔离，最上层消息的路由。一个Virtual host可以若干个Exchange和Queue，同一个Virtual host不能有同名的Exchange或Queue。
Exchange：交换机，接受消息，根据路由键转发消息到绑定的队列上。
banding：Exchange和Queue之间的虚拟连接，binding中可以包括routing key
routing key：一个路由规则，虚拟机根据他来确定如何路由一条消息。
Queue：消息队列，用来存放消息的队列。

Exchange

交换机的类型，direct、topic、fanout、headers，durability（是否需要持久化true需要）auto delete当最后一个绑定Exchange上的队列被删除Exchange也删除。

在这里插入图片描述

Direct Exchange,所有发送到Direct Exchange的消息被转发到RouteKey 中指定的Queue,Direct Exchange可以使用默认的默认的Exchange （default Exchange），默认的Exchange会绑定所有的队列，所以Direct可以直接使用Queue名（作为routing key ）绑定。或者消费者和生产者的routing key完全匹配。
Toptic Exchange,是指发送到Topic Exchange的消息被转发到所有关心的Routing key中指定topic的Queue上。Exchange 将routing key和某Topic进行模糊匹配，此时队列需要绑定一个topic。所谓模糊匹配就是可以使用通配符，“#”可以匹配一个或多个词，“”只匹配一个词比如“log.#”可以匹配“log.info.test” "log. "就只能匹配log.error。
Fanout Exchange:不处理路由键，只需简单的将队列绑定到交换机上。发送到改交换机上的消息都会被发送到与该交换机绑定的队列上。Fanout转发是最快的。

消息如何保证100％投递

什么是生产端的可靠性投递

什么是生产端的可靠性投递

保证消息的成功发出
保证MQ节点节点的成功接收
发送端MQ节点（broker）收到消息确认应答
完善消息进行补偿机制

可靠性投递保障方案

消息落库，对消息进行打标

在这里插入图片描述

消息的延迟投递

在这里插入图片描述
在高并发场景下，每次进行db的操作都是每场消耗性能的。我们使用延迟队列来减少一次数据库的操作。

消息幂等性

幂等性是什么？

我对一个动作进行操作，我们肯能要执行100次1000次，对于这1000次执行的结果都必须一样的。比如单线程方式下执行update count-1的操作执行一千次结果都是一样的，所以这个更新操作就是一个幂等的，如果是在并发不做线程安全的处理的情况下update一千次操作结果可能就不是一样的，所以并发情况下的update操作就不是一个幂等的操作。对应到消息队列上来，就是我们即使受到了多条一样的消息，也和消费一条消息效果是一样的。

高并发的情况下如何避免消息重复消费

唯一id+加指纹码，利用数据库主键去重。

优点：实现简单

缺点：高并发下有数据写入瓶颈。

利用Redis的原子性来实习。

使用Redis进行幂等是需要考虑的问题

是否进行数据库落库，落库后数据和缓存如何做到保证幂等（Redis 和数据库如何同时成功同时失败）？

如果不进行落库，都放在Redis中如何这是Redis和数据库的同步策略？还有放在缓存中就能百分之百的成功吗？

confirm 确认消息、Return返回消息

理解confirm消息确认机制

消息的确认，指生产者收到投递消息后，如果Broker收到消息就会给我们的生产者一个应答，生产者接受应答来确认broker是否收到消息。

如何实现confirm确认消息

在Channel上开启确认模式：channel.confirmSelect()

在channel上添加监听：addConfirmListener，监听成功和失败的结果，具体结果对消息进行重新发送或者记录日志。

return消息机制

Return消息机制处理一些不可路由的消息，我们的生产者通过指定一个Exchange和Routinkey，把消息送达到某一个队列中去，然后我们消费者监听队列进行消费处理！

在某些情况下，如果我们在发送消息的时候当Exchange不存在或者指定的路由key路由找不到，这个时候如果我们需要监听这种不可到达的消息，就要使用Return Listener！

Mandatory 设置为true则会监听器会接受到路由不可达的消息，然后处理。如果设置为false，broker将会自动删除该消息。

消费端自定义监听

消费端限流

什么是消费端的限流？限流算法

假设我们有个场景，首先，我们有个rabbitMQ服务器上有上万条消息未消费，然后我们随便打开一个消费者客户端，会出现：巨量的消息瞬间推送过来，但是我们的消费端无法同时处理这么多数据。

这时就会导致你的服务崩溃。其他情况也会出现问题，比如你的生产者与消费者能力不匹配，在高并发的情况下生产端产生大量消息，消费端无法消费那么多消息。

rabbitMQ提供了一种qos（服务质量保证）的功能，即非自动确认消息的前提下，如果有一定数目的消息（通过consumer或者Channel设置qos）未被确认，不进行新的消费。
prefetchSize:0 单条消息的大小限制。0就是不限制，一般都是不限制。
prefetchCount: 设置一个固定的值，告诉rabbitMQ不要同时给一个消费者推送多余N个消息，即一旦有N个消息还没有ack，则consumer将block掉，直到有消息ack
global：truefalse 是否将上面的设置用于channel，也是就是说上面设置的限制是用于channel级别的还是consumer的级别的。