seo竞价是什么意思,高明公司搜索seo,装修报价器,深圳东门RabbitMQ是基于AMQP协议开发的一个MQ产品#xff0c; 首先我们以Web管理页面为 入口#xff0c;来了解下RabbitMQ的一些基础概念#xff0c;这样我们后续才好针对这些基础概念 进行编程实战。 可以参照下图来理解RabbitMQ当中的基础概念#xff1a; 虚拟主机 virtual hos… 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队列目前还没有合并的打算但是在应用层面来看他们两 者是冲突的是一种竞争关系未来也很有可能最终统一保留成一种类型。至于未 来走向如何我们可以在后续版本拭目以待
