RabbitMQ 知识点_activemq exchange routekey

RabbitMQ 知识点

rabbitmq 的使用场景有哪些？

1. 跨系统的异步通信，所有需要异步交互的地方都可以使用消息队列。就像我们除了打电话（同步）以外，还需要发短信，发电子邮件（异步）的通讯方式。
2. 多个应用之间的耦合，因为消息是平台无关和语言无关的，而且语义上也不再是函数调用，因而更适合作为多个应用之间的松耦合的接口。基于消息队列的耦合，不需要发送方和接收方同时在线。在企业应用集成（EAI）中，文件传输，共享数据库，消息队列，远程过程调用都可以作为集成的方法。
3. 应用内的同步变异步，比方订单解决，即可以由前台应用将订单信息放到队列，后台应用从队列里依次取得消息解决，高峰时的大量订单可以积压在队列里慢慢解决掉。因为同步通常意味着阻塞，而大量线程的阻塞会降低计算机的性能。
4. 消息驱动的架构（EDA），系统分解为消息队列，和消息制造者和消息消费者，一个解决流程可以根据需要拆成多个阶段（Stage），阶段之间用队列连接起来，前一个阶段解决的结果放入队列，后一个阶段从队列中获取消息继续解决。
5. 应用需要更灵活的耦合方式，如发布订阅，比方可以指定路由规则。
6. 跨局域网，甚至跨城市的通讯（CDN行业），比方北京机房与广州机房的应用程序的通信

为什么使用消息队列？

大多数情况下，使用消息队列目的是：：解耦、异步、削峰。

通过一个 MQ，Pub/Sub 发布订阅消息模型，业务间解耦

通过MQ，使得同步的操作变为异步操作，提高效率。

通过MQ，控制服务可以接收到的请求数量，削峰

rabbitmq 有哪些重要的角色？

有：生产者、消费者和代理商：

• 生产者：消息的创立者，负责创立和推送数据到消息服务器；
• 消费者：消息的接收方，用于解决数据和确认消息；
• 中间件：就是 RabbitMQ 本身，本身不生产消息，只是扮演搬运的角色。

rabbitmq 有哪些重要的组件？

• ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。
• Channel（信道）：消息推送使用的通道。
• Exchange（交换器）：用于接受、分配消息。
• Queue（队列）：用于存储生产者的消息。
• RoutingKey（路由键）：用于把生成者的数据分配到交换器上。
• BindingKey（绑定键）：用于把交换器的消息绑定到队列上。

消息队列有什么优缺点

优点就是在特殊场景下有其对应的好处，解耦、异步、削峰

缺点有以下几个：

• 系统可用性降低

系统引入的外部依赖越多，越容易挂掉。需要保证消息队列的高可用

• 系统复杂度提高，保证消息没有重复消费，怎么处理消息丢失的情况，怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
• 一致性问题

A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

如何解决消息丢失

先来分析消息丢失的原因：

1）从生产者弄丢数据这个角度来看：

RabbitMQ提供transaction和confirm模式来确保生产者不丢消息；

transaction机制就是说：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降；

confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；

rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；

如果rabbitMQ没能处理该消息，则会发送一个unack消息给你，你可以进行重试操作。

2）消息队列丢数据：消息持久化。

处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。

这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。

这样，如果消息持久化磁盘之前，rabbitMQ宕机了，那么生产者收不到Ack信号，生产者会自动重发。

那么如何持久化呢？

这里顺便说一下吧，其实也很容易，就下面两步

1. 将queue的持久化标识durable设置为true,则代表是一个持久的队列
2. 发送消息的时候将deliveryMode=2

这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据

3）消费者丢失消息：消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！

消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；

如果这时处理消息失败，就会丢失该消息；

解决方案：处理消息成功后，手动回复确认消息。

总结：

• ack（消费者确认）

• 持久化 （交换机、队列、消息）， message 本身设置 persistent 属性，要求 exchange

  和 queue 都设置 durable 属性。

• 不推荐使用消息事务，会验证降低性能

• 生产者确认（publisher confirm）：生产者发送消息后，等待mq的ACK，如果没有收到或者收到失败信息，则重试。如果收到成功消息则业务结束。

  channel.waitForConfirmsOrDie(10000);
  1

• 可靠消息服务（可选，自己编写逻辑）：对于部分不支持生产者确认的消息队列，可以发送消息前，将消息持久化到数据库，并记录消息状态，后续消息发送、消费等过程都依赖于数据库中消息状态的判断和修改。

如何避免消息堆积

• 通过同一个队列多消费者监听，实现消息的争抢，加快消息消费速度。

如何保证消息的有序性

答：大部分业务对消息的有序性要求不高，如果遇到对时序要求较高的业务，分两种情况来处理：

• 业务同时对并发要求不高：
  • 保证消息发送时有序同步发送
  • 保证消息发送被同一个队列接收
  • 保证一个队列只有一个消费者，可以有从机（待机状态），实现高可用。
  • 实现主从（Zookeeper集群选主）
• 业务同时对并发要求较高：
  • 满足上述第一个场景的条件
  • 可以有多个队列
  • 有时序要求的一组消息，通过hash方式分派到一个固定队列 2 hash -> klsdilelksd

如何避免消息重复消费

• 保证接口幂等即可，那么如何保证接口幂等呢？

  • 某些接口天生幂等，例如查询请求

  • 某些接口天生不幂等，比如新增，还有某些接口的修改功能

    需要根据具体的业务或状态来确定的，在消费端通过业务判断是否执行过

消息基于什么传输？

由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。

RabbitMQ 上的一个 queue 中存放的 message 是否有数量限制？

答：可以认为是无限制，因为限制取决于机器的内存，但是消息过多会导致处理效率的下降

RabbitMQ 概念里的 Channel、Exchange 和 Queue 这些概念

queue 具有自己的 erlang 进程；

exchange 内部实现为保存 binding 关系的查找表；

channel 是实际进行路由工作的实体，即负责按照 routing_key 将 message 投递给 queue 。

由 AMQP 协议描述可知，channel 是真实 TCP 连接之上的虚拟连接，所有 AMQP 命令都是通过 channel 发送的，且每一个 channel 有唯一的 ID。一个 channel 只能被单独一个操作系统线程使用，故投递到特定 channel 上的 message 是有顺序的。

vhost 是什么？起什么作用？

答：vhost 可以理解为虚拟 broker ，即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等，但最最重要的是，其拥有独立的权限系统，可以做到 vhost 范围的用户控制。当然，从 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）。

routing_key 和 binding_key 的最大长度是多少？

255 字节。

消息怎么路由？

从概念上来说，消息路由必须有三部分：交换器、路由、绑定。生产者把消息发布到交换器上；绑定决定了消息如何从路由器路由到特定的队列；消息最终到达队列，并被消费者接收。常用的交换器主要分为一下三种：

• direct：如果路由键完全匹配，消息就被投递到相应的队列
• fanout：如果交换器收到消息，将会广播到所有绑定的队列上
• topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符，比如：“*” 匹配1个文本， “.” 把路由键分为了几部分，“#” 匹配任意数量文本。特别注意：发往topic交换器的消息不能随意的设置选择键（routing_key），必须是由"."隔开的一系列的标识符组成。

在单 node 系统和多 node 构成的 cluster 系统中声明 queue、exchange ，以及进行 binding 会有什么不同？

当你在单 node 上声明 queue 时，只要该 node 上相关元数据进行了变更，你就会得到 Queue.Declare-ok 回应；而在 cluster 上声明 queue ，则要求 cluster 上的全部 node 都要进行元数据成功更新，才会得到 Queue.Declare-ok 回应。另外，若 node 类型为 RAM node 则变更的数据仅保存在内存中，若类型为 disk node 则还要变更保存在磁盘上的数据。

dead letter queue 的用途？

死信队列&死信交换器：DLX 全称（Dead-Letter-Exchange）,称之为死信交换器，当消息变成一个死信之后，如果这个消息所在的队列存在x-dead-letter-exchange参数，那么它会被发送到x-dead-letter-exchange对应值的交换器上，这个交换器就称之为死信交换器，与这个死信交换器绑定的队列就是死信队列。

当消息被 RabbitMQ server 投递到 consumer 后，但 consumer 却通过 Basic.Reject 进行了拒绝时（同时设置 requeue=false），那么该消息会被放入“dead letter”queue 中。该 queue 可用于排查 message 被 reject 或 undeliver 的原因。

RabbitMQ 中的 broker 是指什么？cluster 又是指什么？

broker 是指一个或多个 erlang node 的逻辑分组，且 node 上运行着 RabbitMQ 应用

程序。cluster 是在 broker 的基础之上，增加了 node 之间共享元数据的约束。

什么是元数据？元数据分为哪些类型？包括哪些内容？与 cluster 相关的元数据

1）在非 cluster 模式下，元数据主要分为 Queue 元数据（queue 名字和属性等）、

Exchange 元数据（exchange 名字、类型和属性等）、Binding 元数据（存放路由关系的查

找表）、Vhost 元数据（vhost 范围内针对前三者的名字空间约束和安全属性设置）。在

2）在cluster 模式下，还包括 cluster 中 node 位置信息和 node 关系信息。元数据按照 erlang

node 的类型确定是仅保存于 RAM 中，还是同时保存在 RAM 和 disk 上。元数据在

cluster 中是全 node 分布的。

Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？

中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；

大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。

如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，已经几乎是全世界这个领域的事实性规范。