RabbitMQ基础概念-02

RabbitMQ是基于AMQP协议开发的一个MQ产品， 首先我们以Web管理页面为 入口，来了解下RabbitMQ的一些基础概念，这样我们后续才好针对这些基础概念 进行编程实战。
可以参照下图来理解RabbitMQ当中的基础概念：

虚拟主机 virtual host
这个在之前搭建时已经体验过了。RabbitMQ出于服务器复用的想法，可以在一 个RabbitMQ集群中划分出多个虚拟主机，每一个虚拟主机都有AMQP的全套基础 组件，并且可以针对每个虚拟主机进行权限以及数据分配，并且不同虚拟主机之间 是完全隔离的
连接 Connection
客户端与RabbitMQ进行交互，首先就需要建立一个TPC连接，这个连接就是 Connection。
信道 Channel
一旦客户端与RabbitMQ建立了连接，就会分配一个AMQP信道 Channel。每个 信道都会被分配一个唯一的ID。也可以理解为是客户端与RabbitMQ实际进行数据 交互的通道，我们后续的大多数的数据操作都是在信道 Channel 这个层面展开的。 RabbitMQ为了减少性能开销，也会在一个Connection中建立多个Channel，这 样便于客户端进行多线程连接，这些连接会复用同一个Connection的TCP通道，所 以在实际业务中，对于Connection和Channel的分配也需要根据实际情况进行考 量
交换机 Exchange
这是RabbitMQ中进行数据路由的重要组件。消息发送到RabbitMQ中后，会首 先进入一个交换机，然后由交换机负责将数据转发到不同的队列中。RabbitMQ中 有多种不同类型的交换机来支持不同的路由策略。从Web管理界面就能看到，在每 个虚拟主机中，RabbitMQ都会默认创建几个不同类型的交换机来

交换机多用来与生产者打交道。生产者发送的消息通过Exchange交换机分配到各 个不同的Queue队列上，而对于消息消费者来说，通常只需要关注自己感兴趣的队 列就可以了
队列 Queue
队列是实际保存数据的最小单位。队列结构天生就具有FIFO的顺序，消息最终都 会被分发到不同的队列当中，然后才被消费者进行消费处理。这也是最近 RabbitMQ功能变动最大的地方。最为常用的是经典队列Classic。RabbitMQ 3.8.X 版本添加了Quorum队列，3.9.X又添加了Stream队列。
Classic 经典队列
这是RabbitMQ最为经典的队列类型。在单机环境中，拥有比较高的消息可靠 性。

在这个图中可以看到，经典队列可以选择是否持久化( Durability )以及是否自动 删除(Auto delete )两个属性。 其中，Durability有两个选项，Durable和Transient。 Durable表示队列会将消息 保存到硬盘，这样消息的安全性更高。但是同时，由于需要有更多的IO操作，所以 生产和消费消息的性能，相比Transient会比较低。 Auto delete属性如果选择为是，那队列将在至少一个消费者已经连接，然后所有的 消费者都断开连接后删除自己。 后面的Arguments部分，还有非常多的参数，可以点击后面的问号逐步了解。
Quorum 仲裁队列
仲裁队列，是RabbitMQ从3.8.0版本，引入的一个新的队列类型，整个3.8.X版 本，也都是在围绕仲裁队列进行完善和优化。仲裁队列相比Classic经典队列，在分 布式环境下对消息的可靠性保障更高。官方文档中表示，未来会使用Quorum仲裁 队列代替传统Classic队列。

Quorum是基于Raft一致性协议实现的一种新型的分布式消息队列，他实现了持 久化，多备份的FIFO队列，主要就是针对RabbitMQ的镜像模式设计的。简单理解 就是quorum队列中的消息需要有集群中多半节点同意确认后，才会写入到队列 中。这种队列类似于RocketMQ当中的DLedger集群。这种方式可以保证消息在集 群内部不会丢失。同时，Quorum是以牺牲很多高级队列特性为代价，来进一步保 证消息在分布式环境下的高可靠。 从整体功能上来说，Quorum队列是在Classic经典队列的基础上做减法，因此对 于RabbitMQ的长期使用者而言，其实是会影响使用体验的。他与普通队列的区 别

从官方这个比较图就能看到，Quorum队列大部分功能都是在Classic队列基础上 做减法，比如Non-durable queues表示是非持久化的内存队列。Exclusivity表示独 占队列，即表示队列只能由声明该队列的Connection连接来进行使用，包括队列创 建、删除、收发消息等，并且独占队列会在声明该队列的Connection断开后自动删 除。
其中有个特例就是这个Poison Message(有毒的消息)。所谓毒消息是指消息一直 不能被消费者正常消费(可能是由于消费者失败或者消费逻辑有问题等)，就会导致消 息不断的重新入队，这样这些消息就成为了毒消息。这些读消息应该有保障机制进 行标记并及时删除。Quorum队列会持续跟踪消息的失败投递尝试次数，并记录 在"x-delivery-count"这样一个头部参数中。然后，就可以通过设置 Delivery limit 参数来定制一个毒消息的删除策略。当消息的重复投递次数超过了Delivery limit参
数阈值时，RabbitMQ就会删除这些毒消息。当然，如果配置了死信队列的话，就 会进入对应的死信队列。、
Quorum队列更适合于 队列长期存在，并且对容错、数据安全方面的要求比低延
迟、不持久等高级队列更能要求更严格的场景。 例如 电商系统的订单，引入MQ 后，处理速度可以慢一点，但是订单不能丢失。 也对应以下一些不适合使用的场景：
1、一些临时使用的队列：比如transient临时队列，exclusive独占队列，或者经常 会修改和删除的队列。
2、对消息低延迟要求高： 一致性算法会影响消息的延迟。
3、对数据安全性要求不高：Quorum队列需要消费者手动通知或者生产者手动确
认。
4、队列消息积压严重 ： 如果队列中的消息很大，或者积压的消息很多，就不要使 用Quorum队列。Quorum队列当前会将所有消息始终保存在内存中，直到达到内 存使用极限。
Stream队列
Stream队列是RabbitMQ自3.9.0版本开始引入的一种新的数据队列类型，也是目 前官方最为推荐的队列类型。这种队列类型的消息是持久化到磁盘并且具备分布式 备份的，更适合于消费者多，读消息非常频繁的场景。

Stream队列的核心是以append-only只添加的日志来记录消息，整体来说，就是 消息将以append-only的方式持久化到日志文件中，然后通过调整每个消费者的消 费进度offset，来实现消息的多次分发。下方有几个属性也都是来定义日志文件的大 小以及保存时间。如果你熟悉Kafka或者RocketMQ，会对这种日志记录消息的方式 非常熟悉。这种队列提供了RabbitMQ已有的其他队列类型不太好实现的四个特 点：
1、large fan-outs 大规模分发
当想要向多个订阅者发送相同的消息时，以往的队列类型必须为每个消费者绑定 一个专用的队列。如果消费者的数量很大，这就会导致性能低下。而Stream队列允 许任意数量的消费者使用同一个队列的消息，从而消除绑定多个队列的需求。
2、Replay/Time-travelling 消息回溯
RabbitMQ已有的这些队列类型，在消费者处理完消息后，消息都会从队列中删 除，因此，无法重新读取已经消费过的消息。而Stream队列允许用户在日志的任何 一个连接点开始重新读取数据。
3、Throughput Performance 高吞吐性能
Strem队列的设计以性能为主要目标，对消息传递吞吐量的提升非常明显。
4、Large logs 大日志
RabbitMQ一直以来有一个让人诟病的地方，就是当队列中积累的消息过多时， 性能下降会非常明显。但是Stream队列的设计目标就是以最小的内存开销高效地存 储大量的数据。整体上来说，RabbitMQ的Stream队列，其实有很多地方借鉴了其他MQ产品的 优点，在保证消息可靠性的基础上，着力提高队列的消息吞吐量以及消息转发性 能。因此，Stream也是在视图解决一个RabbitMQ一直以来，让人诟病的缺点，就 是当队列中积累的消息过多时，性能下降会非常明显的问题。RabbitMQ以往更专 注于企业级的内部使用，但是从这些队列功能可以看到，Rabbitmq也在向更复杂的 互联网环境靠拢，未来对于RabbitMQ的了解，也需要随着版本推进，不断更新。 但是，从整体功能上来讲，队列只不过是一个实现FIFO的数据结构而已，这种数 据结构其实是越简单越好。而当前RabbitMQ区分出这么多种队列类型，其实极大 的增加了应用层面的使用难度，应用层面必须有一些不同的机制兼容各种队列。所 以，在未来版本中，RabbitMQ很可能还是会将这几种队列类型最终统一成一种类 型。例如官方已经说明未来会使用Quorum队列类型替代经典队列，到那时，应用 层很多工具就可以得到简化，比如不需要再设置durable和exclusive属性。虽然 Quorum队列和Stream队列目前还没有合并的打算，但是在应用层面来看，他们两 者是冲突的，是一种竞争关系，未来也很有可能最终统一保留成一种类型。至于未 来走向如何，我们可以在后续版本拭目以待