（二）rabbitmq结构介绍

RabbitMq是一个基于AMQP协议开发的一个MQ产品，可以参照下图来理解RabbitMQ的基础概念

1.虚拟主机virtual host

        rabbitMQ出于服务器复用的想法，可以在一个Rabbitmq集群中划分出多个虚拟主机，每个虚拟主机都有AMQP的全套基础组件，并且可以针对每个虚拟主机进行权限数据分配，并且之间是完全隔离的

2.连接Connection

        客户端与RabbitMq进行交互，首先就需要建立一个TCP连接，这个连接就是Connection

3.信道Channel

        3.1 客户端与rabbitMQ建立连接，就会分配一个AMQP协议信道Channel。

        3.2 每个信道都会分配一个唯一ID，也理解为是客户端与RabbitMQ实际进行数据交互的通道，数据操作都是在信道Channel这个层面展开的

        3.3RabbitMQ为了减少性能开销，也会在一个Connection中建立多个Channel，这个便于客户端进行多线程连接，这些连接会复用同一个Connection的TCP通道，所以在实际业务中，对于Connection和Channel的分配也需要根据实际情况进行考量

4.交换机Exchange

        4.1 数据进行路由的重要组件

        4.2 消息发送到RabbitMQ中后，会首 先进入一个交换机，然后由交换机负责将数据转发到不同的队列中

        4.3 交换机多用来与生产者打交道。生产者发送的消息通过Exchange交换机分配到各 个不同的Queue队列上。对于消费者，只需要关注队列就可以了

5.队列Queue

        队列是实际保存数据的最小单位。队列结构天生就具有FIFO的顺序

        5.1 Classic 经典队列 。在单机环境中，拥有比较高的消息可靠性

        

        5.1.1 经典队列可以选择是否持久化(Durability)以及是否自动删除(Auto delete)两个属性Durability有两个选项，Durable和Transient。 Durable表示队列会将消息保存到硬盘，这样消息的安全性更高。但是同时，由于需要有更多的IO操作，所以生产和消费消息的性能，相比Transient会比较低

Auto delete属性如果选择为是，那队列将在至少一个消费者已经连接，然后所有的消费者都断开连接后删除自己

        5.2 Quorum 仲裁队列。仲裁队列，是RabbitMQ从3.8.0版本，引入的一个新的队列类型，整个3.8.X版本，也都是在围绕仲裁队列进行完善和优化。仲裁队列相比Classic经典队列，在分布式环境下对消息的可靠性保障更高。官方文档中表示，未来会使用Quorum仲裁队列代替传统Classic队列

        5.2.1 Quorum是基于Raft一致性协议实现的一种新型的分布式消息队列，他实现了持久化，多备份的FIFO队列，主要就是针对RabbitMQ的镜像模式设计的。就是quorum队列中的消息需要有集群中多半节点同意确认后，才会写入到队列 中。同时，Quorum是以牺牲很多高级队列特性为代价，来进一步保证消息在分布式环境下的高可靠

        5.2.2 Quorum队列大部分功能都是在Classic队列基础上做减法。

        Non-durable queues表示是非持久化的内存队列。

        Exclusivity表示独占队列，即表示队列只能由声明该队列的Connection连接来进行使用，包括队列创建、删除、收发消息等，并且独占队列会在声明该队列的Connection断开后自动删除

有个特例就是这个Poison Message(有毒的消息)。所谓毒消息是指消息一直不能被消费者正常消费(可能是由于消费者失败或者消费逻辑有问题等)，就会导致消息不断的重新入队，这样这些消息就成为了毒消息。这些读消息应该有保障机制进行标记并及时删除。Quorum队列会持续跟踪消息的失败投递尝试次数，并记录

在"x-delivery-count"这样一个头部参数中。然后，就可以通过设置 Delivery limit 参数来定制一个毒消息的删除策略。当消息的重复投递次数超过了Delivery limit参数阈值时，RabbitMQ就会删除这些毒消息。当然，如果配置了死信队列的话，就会进入对应的死信队列

Quorum 队列更适合于 队列长期存在，并且对容错、数据安全方面的要求比低延迟、不持久等高级队列更能要求更严格的场景

        5.3 Stream队列

        Stream队列是RabbitMQ自3.9.0版本开始引入的一种新的数据队列类型，也是目前官方最为推荐的队列类型。这种队列类型的消息是持久化到磁盘并且具备分布式备份的，更适合于消费者多，读消息非常频繁的场景

         Stream队列的核心是以append-only只添加的日志来记录消息，整体来说，就是消息将以append-only的方式持久化到日志文件中，然后通过调整每个消费者的消费进度offset，来实现消息的多次分发。下方有几个属性也都是来定义日志文件的大小以及保存时间，如果你熟悉Kafka或者RocketMQ，会对这种日志记录消息的方式非常熟悉。这种队列提供了RabbitMQ已有的其他队列类型不太好实现的四个特 点：

        5.3.1  large fan-outs 大规模分发

        当想要向多个订阅者发送相同的消息时，以往的队列类型必须为每个消费者绑定一个专用的队列。如果消费者的数量很大，这就会导致性能低下。而Stream队列允许任意数量的消费者使用同一个队列的消息，从而消除绑定多个队列的需求

        5.3.2  Replay/Time-travelling                    消息回溯RabbitMQ

已有的这些队列类型，在消费者处理完消息后，消息都会从队列中删 除，因此，无法重新读取已经消费过的消息。而Stream队列允许用户在日志的任何一个连接点开始重新读取数据。

        5.3.3 Throughput                     Performance                     高吞吐性能Strem队列的设计以性能为主要目标，对消息传递吞吐量的提升非常明显。

        5.3.4 Large logs 大日志 RabbitMQ一直以来有一个让人诟病的地方，就是当队列中积累的消息过多时， 性能下降会非常明显。但是Stream队列的设计目标就是以最小的内存开销高效地存储大量的数据。