03-RabbitMQ之基础概念_rabbitmq消息回溯

一、RabbitMQ基础概念
RabbitMQ是基于AMQP协议开发的一个MQ产品，我们以Web控制台管理页面为入口，同时参照下图来理解RabbitMQ当中的基础概念

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

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

• Durability：Durability有两个选项，Durable和Transient。Durable表示队列会将消息保存到硬盘，这样消息的安全性更高。但是需要有更多的IO操作，所以生产和消费消息的性能，相比Transient会比较低
• Auto delete：如果选择为是，队列会在所有消费者断开连接后自动删除

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

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

从整体功能上来说，Quorum队列是在Classic经典队列的基础上做减法，它与普通队列的区别：

使用场景：

• 队列长期存在
• 对容错、数据安全方面的要求比较高，能容忍响应慢些
• 不用持久化

不适合使用的场景：

• 一些临时使用的队列：比如transient临时队列，exclusive独占队列，或者经常会修改和删除的队列
• 对消息低延迟要求高：一致性算法会影响消息的延迟
• 对数据安全性要求不高：Quorum队列需要消费者手动通知或者生产者手动确认
• 队列消息积压严重：如果队列中的消息很大，或者积压的消息很多，就不要使用Quorum队列。Quorum队列当前会将所有消息始终保存在内存中，直到达到内存使用极限

(3)Stream队列
Stream队列是RabbitMQ自3.9.0版本开始引入的一种新的数据队列类型，也是目前官方最为推荐的队列类型。这种队列类型的消息是持久化到磁盘并且具备分布式备份的，更适合于消费者多，读消息非常频繁的场景。
Stream队列的核心是以append-only只添加的日志来记录消息，消息将以append-only的方式持久化到日志文件中，然后通过调整每个消费者的消费进度offset，来实现消息的多次分发。具有以下四个特点：

• large fan-outs 大规模分发：当想要向多个订阅者发送相同的消息时，以往的队列类型必须为每个消费者绑定一个专用的队列。如果消费者的数量很大，这就会导致性能低下。Stream队列允许任意数量的消费者使用同一个队列的消息，从而消除绑定多个队列的需求
• Replay/Time-travelling 消息回溯：RabbitMQ已有的这些队列类型，在消费者处理完消息后，消息都会从队列中删除，因此无法重新读取已经消费过的消息。而Stream队列允许用户在日志的任何一个连接点开始重新读取数据
• Throughput Performance 高吞吐性能：Strem队列的设计以性能为主要目标，对消息传递吞吐量的提升非常明显
• Large logs 大日志：RabbitMQ一直以来有一个让人诟病的地方，就是当队列中积累的消息过多时，性能下降会非常明显。Stream队列的设计目标就是以最小的内存开销高效地存储大量的数据

整体上来说，RabbitMQ的Stream队列，其实有很多地方借鉴了其他MQ产品的优点，在保证消息可靠性的基础上，着力提高队列的消息吞吐量以及消息转发性能。因此Stream也是在试图解决RabbitMQ一直以来让人诟病的缺点，就是当队列中积累的消息过多时，性能下降会非常明显的问题。RabbitMQ以往更专注于企业级的内部使用，但是从这些队列功能可以看到，Rabbitmq也在向更复杂的互联网环境靠拢，未来对于RabbitMQ的了解，也需要随着版本推进不断更新

但是从整体功能上来讲，队列只不过是一个实现FIFO的数据结构而已，这种数据结构其实是越简单越好。而当前RabbitMQ区分出这么多种队列类型，其实极大的增加了应用层面的使用难度，应用层面必须有一些不同的机制兼容各种队列。所以在未来版本中，RabbitMQ很可能还是会将这几种队列类型最终统一成一种类型。例如官方已经说明未来会使用Quorum队列类型替代经典队列，到那时应用层很多工具就可以得到简化，比如不需要再设置durable和exclusive属性。虽然
Quorum队列和Stream队列目前还没有合并的打算，但是在应用层面来看，它们两者是冲突的，是一种竞争关系，未来也很有可能最终统一保留成一种类型。