街蝉

深浅模式

作者：街蝉
更新：9/9/2024
字数：0字
阅读时长：约0分钟

MQ篇(针对RabbitMQ) ​

MQ篇口语回答

本篇记录了关于 MQ 的口语话回答

对于本篇, 以分割线为界, 分割线以上是口语话回答, 重点背, 分割线以下是详细内容, 重点看

看熟了才背的会

1. MQ 使用场景有哪些? ​

消息队列（MQ）在分布式服务架构中主要用于流量削峰和系统解耦。作为发送方，它的主要作用是将业务数据变化通知其他系统（或自身的其他部分），而不需要关心消费方的具体实现细节。作为消费方，则需要关注如何处理消息以及实现业务逻辑。

具体应用场景包括：用户下单后通知订单状态的变化，实现功能解耦；在秒杀场景中，通过 MQ 处理秒杀资格订单，确保秒杀过程的高性能；对于一些可以与主流程分离且不需立即处理的任务，如发送邮件或短信，也可以使用 MQ；此外，数据同步场景也可以通过 MQ 实现。

详细介绍：

  • 异步通信场景: MQ可以实现消息的异步传递，避免了请求等待的时间，提高了系统的响应速度和吞吐量。常见的应用场景有异步下单、异步支付等，例如在电商平台中，当用户下单或支付后，这些操作可以被转化为消息发送至MQ，由后台服务异步处理，而用户无需等待操作完成即可进行其他操作。

  • 分布式系统场景: MQ可以在分布式系统中实现各个节点之间的高效通信，解决网络延迟、网络抖动等问题。常见的应用场景有分布式任务调度、分布式事务等。例如，在微服务架构中，服务之间的数据交互可以通过MQ实现，降低服务的耦合度，提高系统的可扩展性和可维护性。

  • 解耦系统场景: MQ可以将系统各个模块之间的耦合度降低，实现系统的解耦，常见的应用场景有日志收集、异常监控等。通过使用MQ，可以将这些操作从主业务逻辑中分离出来，降低系统的复杂性。

  • 流量削峰场景: MQ可以在高并发场景下，实现流量的削峰，避免系统崩溃或响应变慢。常见的应用场景有秒杀、活动抢购等。通过使用MQ缓存请求，后台服务可以按顺序处理，避免大量请求直接冲击系统。

  • 消息通知场景: MQ可以实现消息的实时通知，提高用户体验。常见的应用场景有订单状态变更通知、短信验证码发送等。用户可以在无需主动查询的情况下，实时获取到最新的信息。

  • 数据同步场景: MQ可以实现不同系统之间数据的同步，保证数据的一致性。常见的应用场景有缓存同步、库存同步等。当某个系统修改了共享数据后，可以通过MQ通知其他系统同步数据。

2. 为什么要使用MQ? MQ常见的作用? ​

TIP

重点 : 流量削峰 + 系统解耦

随着业务的不断发展，业务逻辑变得越来越复杂，比如用户下单后可能会触发各种优惠活动、发送通知等。如果将所有这些逻辑写在下单操作中，系统将变得难以维护。使用消息队列（MQ）可以通过异步处理将这些与核心逻辑无关的业务操作转移到其他服务或模块，实现功能之间的解耦。此外，当系统面临大量流量时，消息队列可以通过异步处理或延迟处理来平稳流量，防止系统因高并发而崩溃，从而实现流量削峰。

详细介绍：

  1. 解耦: 消息队列可以将不同系统或服务之间解耦。发送者只需将消息发送到队列中，而不需要了解接收者的细节。接收者可以独立地从队列中读取消息并处理。这样，发送者和接收者可以独立开发、部署和扩展。比如在电商平台中，用户下单后，订单服务将订单信息发送到消息队列，支付服务、库存服务和通知服务可以独立地从队列中读取订单信息并处理，而不需要直接调用这些服务。

  2. 异步处理: 消息队列可以将一些耗时的操作异步处理，从而提高系统的响应速度和用户体验。例如，用户注册后发送欢迎邮件可以异步处理，用户不需要等待邮件发送完成。用户注册后，注册服务将用户信息发送到消息队列，邮件服务从队列中读取消息并发送欢迎邮件，用户可以立即得到注册成功的反馈。

  3. 削峰填谷: 在高并发场景下，消息队列可以缓冲突发流量，防止系统过载。通过将突发请求放入队列中，系统可以平稳地处理这些请求，避免瞬时高并发导致系统崩溃。例如，在秒杀活动中，订单请求量可能会激增。将订单请求放入消息队列，后端服务可以根据处理能力从队列中读取请求并处理，从而避免系统崩溃。

  4. 可靠性: 消息队列通常提供消息持久化和重试机制，确保消息不会丢失。这对于需要保证消息传递可靠性的场景非常重要。例如，在金融交易系统中，交易请求需要确保不丢失。通过消息队列的持久化和重试机制，可以确保交易请求可靠地传递和处理。

3. 消息队列会有什么缺点吗? ​

在使用消息队列（MQ）时，我们需要关注两个主要问题。第一个是削峰，虽然消息队列可以缓解瞬时高并发带来的压力，但它也可能引发一些问题，比如消息丢失、延迟较大、重复消费等。为了应对这些问题，我们需要考虑更多的机制来保障消息的可靠性。第二个是解耦，虽然消息队列可以让系统之间的业务逻辑更清晰，但它也会增加系统间的复杂度，因为与接口对接相比，消息队列的对接更加复杂，这提高了系统的维护和学习成本。此外，各系统之间的一致性问题也需要特别关注。

详解：

  1. 系统复杂性增加: 引入消息队列会增加系统的复杂性，包括系统架构、开发和运维的复杂性。需要处理消息的生产、消费、路由、持久化、重试、重复消息处理等问题。在简单的单体应用中，引入消息队列需要重新设计系统架构，并开发和维护消息生产者和消费者代码，从而增加系统的复杂性。

  2. 消息丢失风险: 尽管大多数消息队列系统提供了消息持久化和重试机制，但在极端情况下（如硬件故障、网络故障等），仍然存在消息丢失的风险。网络分区或硬盘故障可能导致消息丢失，影响关键操作的处理，如订单处理中的支付请求。

  3. 消息重复: 消息队列系统可能会因网络故障或消费者处理失败而重发消息，导致消息重复。消费者需要具备幂等性，能够正确处理重复消息。例如，在支付系统中，重复处理支付请求可能导致用户多次扣款。因此，消费者需要确保每个支付请求只处理一次。

  4. 延迟: 消息队列引入了额外的网络传输和排队时间，这可能会导致消息处理的延迟。对于实时性要求高的系统，这可能是一个问题。例如，在实时交易系统中，消息处理的延迟可能影响交易的及时性和准确性，从而影响用户体验和系统的可靠性。

  5. 运维成本: 消息队列系统需要专门的运维和监控，确保其高可用性和性能。这包括集群管理、节点监控、日志分析、性能调优等。像 Kafka、RabbitMQ 等消息队列系统需要专门的运维人员进行日常管理和维护，包括集群扩展、故障处理、性能调优等。

  6. 一致性问题: 在分布式系统中，使用消息队列可能导致数据一致性问题。需要设计合理的事务管理和一致性保障机制。例如，在订单系统中，订单创建和库存扣减需要保证一致性。如果订单创建成功但库存扣减失败，可能会导致数据不一致，需要设计补偿机制来处理这种情况。

4. MQ 可能会有哪些常见问题? ​

消息队列主要面临几个问题，包括消息丢失、重复和顺序性。消息丢失可能发生在发送、队列中或者消费时。为避免这些问题，我们可以在发送时进行验证，使用持久化机制（多数 MQ 自带 RAID 策略），以及在消费时实现确认机制（ack）。重复问题可以通过幂等性处理来解决，确保消息不会被多次处理。顺序性问题可以通过使用顺序队列模式或者分区机制来保证消息的正确消费顺序。

5. 如何保障消费的顺序消费? ​

在处理顺序消费问题时，我们通常面临几个挑战，比如多个消费者同时处理消息会打乱顺序，分区机制可能使消息在不同分区内顺序混乱，重试机制也可能引发消息顺序问题。解决这些问题的方法包括使用顺序队列来保证消息按顺序处理，利用分区键将相关消息分到同一分区，或者使用单消费者模式来确保顺序处理。此外，可以通过业务逻辑兼容处理顺序问题，比如在新增和删除消息时，先检查状态以避免处理顺序混乱。

详细解释：

  1. 多个消费者并行处理: 当多个消费者并行处理消息时，消息的处理顺序可能会与发送顺序不一致。例如，两个消费者同时处理同一个队列中的消息，如果没有特殊的限制，就可能出现顺序混乱的情况。

  2. 分区机制: 在分布式消息队列系统中，消息通常会被分区存储和处理。不同分区内的消息顺序可能会被打乱，因此需要注意分区的配置和处理方式。

  3. 重试机制: 如果消息处理失败，重试机制可能会导致消息顺序被打乱。例如，重发的消息可能会在原有消息之前被处理，影响整体的顺序。

解决方案:

  1. 使用顺序队列: 顺序队列确保消息按照发送的顺序进行处理。像Kafka可以通过单个分区来保证顺序性，因为同一分区内的消息是按顺序存储和处理的。

  2. 使用消息分区键: 设置消息分区键来确保同一分区内的消息按顺序处理。分区键通常是业务相关的标识符，如订单ID、用户ID等，这样可以确保相关消息被发送到同一分区并按顺序处理。

  3. 单消费者模式: 使用单消费者模式，即一个队列只有一个消费者，确保消息按顺序处理。在某些情况下，可以在消息队列系统中配置为单消费者模式来避免顺序问题。

  4. 消息排序: 在消费端进行消息排序也可以解决顺序问题。消费者在处理消息前，对消息进行排序，确保处理顺序。这种方法适用于固定时间内的批量处理，但实际操作中可能较为复杂。

6. 如何避免消息丢失? ​

消息丢失是一个重要问题，涉及消息的生产、传输、存储和消费四个阶段。首先，生产阶段的丢失可能是消息未实际发出但程序认为已发出的情况。为了避免这种情况，我们需要确保发送消息时没有报错。如果出现问题，我们应及时捕获异常。传输阶段，MQ需要通过确认机制来保证消息被成功接收。存储阶段，消息需要持久化，一般MQ都有持久化策略，如RAID或镜像复制。最后，在消费阶段，通过ACK机制来确认消息是否被成功处理，这样MQ才会认为消息已被正确消费。

详细解释：

  1. 消息生产过程中的可靠性保证

    • 确保消息成功发送到消息队列系统。例如，Kafka可以通过acks配置设置为all来确保消息被所有副本确认。RabbitMQ则使用发布确认（publisher confirms）机制来确保消息被队列接收。
    • 在RabbitMQ中，可以使用如下代码启用发布确认机制：
      java
      ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
try (Connection connection = factory.newConnection(); Channel channel = connection.createChannel()) {
    channel.confirmSelect(); // 启用发布确认
    String message = "Hello world!";
    channel.basicPublish("my-queue", null, message.getBytes());
    if (channel.waitForConfirms()) {
        System.out.println("Message sent successfully");
    } else {
        System.out.println("Message send failed");
    }
}

  2. 消息传输过程中的可靠性保证

    • 网络传输中可能会失败，需要使用重试机制。同时，使用TCP协议可以提高消息传输的可靠性。

  3. 消息存储过程中的可靠性保证

    • 确保消息在磁盘上持久化存储。Kafka默认情况下会持久化消息。RabbitMQ需要设置队列和消息为持久化。
    • 在RabbitMQ中设置持久化的代码示例如下：
      java
      ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
try (Connection connection = factory.newConnection(); Channel channel = connection.createChannel()) {
    boolean durable = true; // 设置队列持久化
    channel.queueDeclare("my-queue", durable, false, false, null);
    String message = "Hello world!";
    AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
            .deliveryMode(2) // 设置消息持久化
            .build();
    channel.basicPublish("", "my-queue", props, message.getBytes());
}

  4. 消息消费过程中的可靠性保证

    • 消息确认机制（Consumer Acknowledgment）确保消息在成功处理后才从队列中删除。例如，RabbitMQ使用手动确认机制。
    • 在RabbitMQ中，使用手动确认机制的代码如下：
      java
      ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
try (Connection connection = factory.newConnection(); Channel channel = connection.createChannel()) {
    boolean autoAck = false; // 禁用自动确认
    channel.basicConsume("my-queue", autoAck, (consumerTag, delivery) -> {
        String message = new String(delivery.getBody(), "UTF-8");
        System.out.println("Received: " + message);
        channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); // 手动确认
    }, consumerTag -> {});
}

  5. 其他注意事项

    • 监控和报警: 实时监控消息队列系统的运行状态，设置报警机制，及时发现和处理消息丢失问题。
    • 日志记录: 记录消息的生产、传输、存储和消费日志，以便问题排查和恢复。
    • 消息重试机制: 配置合理的消息重试机制，确保在处理失败时能够进行重试。
    • 高可用部署: 部署高可用集群，确保在节点故障时系统能够自动切换，避免消息丢失。

7. 如何避免消息重复投递或重复消费? ​

在消息队列中，重复消费是一个常见的问题，处理不当可能会引发重复扣钱或重复减库存等问题。为了避免这种情况，最重要的是确保消息消费的幂等性，也就是说，不管一个消息被处理多少次，结果都应该是一样的。实现幂等性的方法包括：给每条消息一个唯一标识，使用去重表记录已经处理过的消息，或者确保业务逻辑本身是幂等的，比如扣款操作要确保不会重复扣款。

另外，在消息投递方面，可以通过使用MQ的投递确认机制来避免重复。例如，RocketMQ提供了多种投递机制，确保消息被可靠地发送到Broker，并且发送方能收到确认。对于发送方，也可以使用去重策略来避免重复投递。

最后，要注意消费进度的管理，尤其是有位点概念的MQ。消费者在处理完消息后需要及时提交消费位点，这样即使消费者重启，也能从上次的位置继续消费，防止重复消费。

详细解释：

  1. 消息幂等性

    • 唯一标识: 每条消息附带一个唯一标识（如UUID），处理消息时先检查是否已经处理过。
    • 去重表: 使用数据库或缓存系统（如Redis）记录处理过的消息标识，避免重复处理。
    • 业务逻辑幂等性: 确保业务操作本身是幂等的，例如扣款操作确保同一笔交易不会被重复扣款。

  2. 消息投递机制

    • 同步投递: 例如在RocketMQ中，选择同步投递可以确保消息被可靠地发送到Broker，并且发送方能收到确认。
    • 消息重试机制: RocketMQ提供消息重试机制，当消息投递失败时，会自动重试。可以通过设置合理的重试次数和间隔时间来减少重复投递的可能性。

  3. 消费进度管理

    • 消费位点: 管理消费进度，RocketMQ通过消费位点（Offset）来跟踪消费者的消费进度。消费者在处理完消息后需要定期提交消费位点到Broker，以便在消费者重启后从上次提交的位置继续消费。
    • 持久化存储: 消费位点可以存储在Broker或外部存储系统（如数据库、Zookeeper）中，确保在消费者故障恢复后能够继续消费。

8. 消息重复消费的原因有哪些? ​

首先，发送方逻辑错误或重放可能导致消息重复发送。比如，发送方代码出错，或者出于某种原因故意重发消息。

其次，MQ的重试机制也会导致重复，如果消费者处理失败或者没有及时确认（ack），MQ可能会重新发送消息。

另外，实例重启或位点提交失败也是常见原因。如果消费者实例重启，或者位点提交失败，MQ可能认为某些消息还没有被消费，所以会重新发送。

为了应对这些情况，确保消费者处理的 幂等性 非常重要。只要处理得当，无论多少次重复消费，结果都是一致的。

9. 死信队列和延迟队列是什么? ​

在消息队列中，死信队列和延迟队列解决了不同的问题。死信队列 处理那些处理失败的消息，比如消费多次还是失败的消息，这些消息被称为“死信消息”。通过将这些消息放入死信队列，我们可以避免影响正常消息流，后续再做特别处理，比如人工干预或监控。

延迟队列则是为了处理那些需要在特定时间后，会在设定的延迟时间到达后才被投递到目标队列供消费者消费。比如你希望某个任务在特定时间后触发，或者因为主从数据库同步延迟时，可以设置延迟队列稍后消费消息。

死信队列 (DLQ)

  • 用途: 存储无法被正常处理的消息（死信消息），例如消费多次失败、消息超时或被拒绝。

  • 使用场景:

    • 错误处理: 处理多次失败的消息，进行人工干预或特殊处理。
    • 监控和报警: 监控死信队列，发现并处理系统异常。
    • 消息审计: 审计死信队列中的消息，分析问题。

  • 实现方法:

    • 配置死信策略: 设置最大重试次数、消息存活时间等。
    • 专用死信队列: 为每个队列配置一个专门的死信队列。
    • 消费者处理: 设置消费者处理死信消息，进行记录、报警等处理。

延迟队列

  • 用途: 存储需要在指定时间后才能消费的消息。

  • 使用场景:

    • 定时任务: 调度定时任务，如发送通知或执行操作。
    • 重试机制: 消息处理失败后，延迟再处理。

  • 实现方法:

    • 消息定时属性: 设置消息的延迟时间、到期时间等。
    • 时间轮算法: 管理延迟消息，定时检查并投递到目标队列。

10. 如何解决消息队列的延时以及过期失效问题? ​

消息队列的延迟问题主要有两个方面：

  1. 消费方的延迟: 可以通过增加消费者实例来提升处理速度，或者优化消费逻辑，比如使用批量处理或异步处理，减少每条消息的处理时间。

  2. 消息队列的瓶颈: 这可能是由于队列配置不足或分区数不够。可以通过增加队列的分区数来提高并发处理能力，也可以调整配置参数，如增加内存缓冲区和优化网络设置。

消息过期失效的情况通常是因为过期时间设置不合理。可以通过调整过期时间来解决。如果调整困难，可以将过期消息转移到死信队列进行处理。

解决消息队列的延时问题

  1. 增加消费者实例: 提高并发度，减少消息等待时间。
  2. 优化消费者处理逻辑: 减少处理时间，如批量处理、异步处理、减少不必要的计算和 I/O 操作。
  3. 调整消息队列的分区: 增加分区数，允许更多消费者并行处理。
  4. 调整消息队列的配置: 如增加内存缓冲区大小、优化网络配置，减少传输和处理的延时。

解决消息过期失效问题

  1. 设置合理的消息过期时间: 根据业务需求调整过期时间。
  2. 使用死信队列 (DLQ): 将处理失败或过期的消息转移到死信队列，进行后续处理或人工干预。

11. 如果产生了消息积压问题如何解决? ​

在一个运行正常的系统中，消息积压通常是因为生产者短时间内产生了大量消息，而消费方处理这些消息的速度相对较慢。要解决这个问题，我们可以从两个方面入手。

首先，从生产者的角度分析，检查是否产生了异常的流量。如果是正常的流量，可以考虑引入限流和降级机制，以减少消息的生产量，从而避免系统过载。

其次，从消费方的角度来看，短期内可以通过增加消费实例来提升消费速度。此外，也需要评估消费者的处理逻辑，是否可以通过优化代码来提高处理效率，从而加快消息的消费速度。

通过这两个方面的调整，可以有效地减少消息积压，提升系统的整体性能。

12. Kafka, ActiveMQ, RabbitMQ, RocketMQ有什么优缺点? ​

Apache Kafka、ActiveMQ、RabbitMQ 和 Apache RocketMQ 都是流行的消息队列系统，每种系统都有其优缺点。

Apache Kafka 的强项在于高吞吐量和可靠性，它能处理非常高的消息量，并且支持消息的持久化和副本机制，保证数据的可靠性。它的扩展性也很强，可以通过增加分区和代理来扩展。不过，Kafka 的运维比较复杂，需要专门的管理人员，而且相比一些内存中的消息系统，它的延迟会稍高。此外，Kafka 在一些高级特性方面，比如消息路由和优先级队列，功能较为单一。

ActiveMQ 提供了丰富的特性，支持多种消息传递模型和协议，如点对点和发布-订阅模式、AMQP、MQTT 等。它的使用和部署相对简单，适合中小型企业。但在高吞吐量和高并发的场景下，它的性能表现不如 Kafka 和 RocketMQ，且扩展性也较有限。

RabbitMQ 以灵活的路由机制著称，它支持多种消息路由和协议，适用性广。它也具备高可靠性，支持消息持久化和确认机制。然而，在极高吞吐量和低延迟的场景下，它的性能逊色于 Kafka 和 RocketMQ，并且在大规模集群中，运维复杂度较高，同时处理大量消息时会消耗较多内存。

Apache RocketMQ 则在高性能、强大的消息路由和分布式事务支持方面表现突出。它也有很好的扩展性，能够轻松扩展集群规模，并且支持消息的持久化和副本机制。然而，像 Kafka 一样，RocketMQ 的运维也比较复杂，需要专业的技术知识。

注意

注意, 下方问题 针对于RabbitMQ

1. RabbitMQ 基本概念有哪些? ​

RabbitMQ 是一个开源的消息代理软件，主要用于消息队列和消息传递系统。它基于高级消息队列协议（AMQP），提供了可靠性、高可用性和灵活性。下面是一些 RabbitMQ 的核心概念：

生产者（Producer）是发送消息到 RabbitMQ 的应用程序。它将消息发送到交换机（Exchange），而不是直接发送到队列。

消费者（Consumer）是从 RabbitMQ 队列中接收和处理消息的应用程序。消费者从指定的队列中拉取消息进行处理。

消息（Message）是由生产者发送、消费者接收的基本数据单元。消息通常包含有效载荷（payload）和元数据（如路由键、头部信息等）。

队列（Queue）是 RabbitMQ 中存储消息的缓冲区。消息被发送到队列中，等待消费者处理。队列支持消息持久化和优先级等特性。

交换机（Exchange）是 RabbitMQ 的消息路由组件。生产者将消息发送到交换机，交换机根据路由规则将消息分发到一个或多个队列。交换机有几种类型：

  • Direct Exchange：根据路由键精确匹配队列。
  • Fanout Exchange：将消息广播到所有绑定的队列。
  • Topic Exchange：根据路由键模式（支持通配符）匹配队列。
  • Headers Exchange：根据消息头部属性匹配队列。

绑定（Binding）是交换机和队列之间的连接关系。通过绑定，交换机可以将消息路由到一个或多个队列，绑定可以有路由键用于匹配消息的路由键。

路由键（Routing Key）是生产者在发送消息时指定的字符串，用于交换机将消息路由到绑定的队列。不同类型的交换机对路由键的处理方式不同。

虚拟主机（Virtual Host）是 RabbitMQ 中的逻辑隔离机制，用于隔离不同的应用程序或租户。每个虚拟主机有自己的队列、交换机、绑定等资源。

连接（Connection）是生产者或消费者与 RabbitMQ 服务器之间的 TCP 连接。一个连接可以包含多个信道（Channel）。

信道（Channel）是建立在连接之上的虚拟连接。生产者和消费者通过信道与 RabbitMQ 服务器通信，信道提供了高效的方式来复用 TCP 连接，减少连接开销。

确认（Acknowledgement）是消费者在成功处理消息后发送给 RabbitMQ 的信号，表示消息已经被成功处理。RabbitMQ 收到确认后会将消息从队列中移除。如果消费者未能确认消息，RabbitMQ 会重新投递消息。

持久化（Durability）是指将队列和消息保存到磁盘，以便在 RabbitMQ 重启后仍然存在。这提高了系统的可靠性。

2. RabbitMQ 有几种广播类型? ​

RabbitMQ 中的广播机制主要通过交换机（Exchange）实现。以下是四种主要的广播类型：

  1. Fanout Exchange： Fanout Exchange 是最常见的广播类型。它会将接收到的每条消息广播到所有绑定到该交换机的队列，而不考虑消息的路由键。这使得 Fanout Exchange 特别适合需要将消息分发给多个消费者的场景，比如发布/订阅模式。

  2. Topic Exchange： Topic Exchange 通过路由键模式匹配实现广播。它支持使用通配符（如 * 匹配一个单词，# 匹配零个或多个单词）来定义复杂的路由规则，将消息广播到符合模式的多个队列。它适用于需要更复杂路由规则的场景，如多种订阅模式。

  3. Direct Exchange： Direct Exchange 根据消息的路由键将消息定向传递到绑定的队列。每个队列在绑定时需要指定一个路由键，只有当消息的路由键与队列的路由键完全匹配时，消息才会被传递到该队列。此模式适用于将消息发送到特定队列的场景，例如，根据日志级别（info、warning、error）将消息发送到不同的队列。

  4. Headers Exchange： Headers Exchange 是基于消息头部属性进行路由的。虽然它不是一种典型的广播机制，但可以通过设置特定的头部属性将消息路由到多个队列。Headers Exchange 使用消息头部属性来确定消息的路由，适用于需要基于消息元数据进行复杂路由的场景。

总结：

  • Fanout Exchange：不考虑路由键，直接广播到所有绑定队列，适合简单的发布/订阅模式。
  • Topic Exchange：基于路由键模式匹配，支持通配符，适用于复杂的路由规则。
  • Direct Exchange：根据精确的路由键匹配，适合将消息发送到特定队列。
  • Headers Exchange：基于消息头部属性进行路由，适用于需要基于消息元数据的路由需求。

3. RabbitMQ 基于什么协议传输? ​

RabbitMQ 是基于 AMQP（高级消息队列协议）进行消息传输的。AMQP 是一个开放的应用层协议，它确保了消息的可靠传递，不论是不同的客户端还是中间件产品，都可以通过这个协议进行通信。RabbitMQ 实现了 AMQP 的完整功能，支持多种交换机类型、消息确认、持久化和优先级等功能。AMQP 的三大特性使 RabbitMQ 能够提供高可靠性、灵活性和跨平台支持，使得它在处理复杂的消息路由和分发时表现出色。

详细解释：

RabbitMQ 使用 AMQP（高级消息队列协议）作为其消息传输协议。AMQP 是一个开放标准的应用层协议，设计用于面向消息的中间件。它允许客户端与消息中间件之间进行消息传递，跨越客户端/中间件产品和开发语言的限制。RabbitMQ 实现了 AMQP 协议的完整功能，提供了以下主要特点：

  1. 可靠性：AMQP 协议通过消息确认和持久化机制，确保消息在传输过程中不会丢失，从而实现可靠的消息传递。
  2. 灵活性：AMQP 协议提供了队列、路由、交换机等功能，使得消息中间件可以支持复杂的消息路由和分发策略。
  3. 跨平台性：AMQP 协议的多语言 API 允许跨平台应用开发，使 RabbitMQ 能够与多种编程语言编写的应用程序集成。

4. RabbitMQ 如何避免消息丢失? ​

口语化回答：

RabbitMQ 主要通过几种机制来保证消息不丢失。首先是持久化机制，在创建队列和发送消息时，可以设置为持久化，这样消息会被写入磁盘，即使系统重启也不会丢失。其次是 确认机制，当消费者成功处理完消息后，会发送一个 ack 确认信号给 RabbitMQ，只有在收到确认信号后，RabbitMQ 才会将消息从队列中移除。如果没有收到确认信号，RabbitMQ 会重新投递消息，确保不会丢失。再有就是镜像队列，这种机制类似于 Redis 的主从复制，确保一个节点出现问题时，其他节点仍然能够存储消息，保证高可用性。这些机制一起工作，确保 RabbitMQ 能够可靠地处理消息。

详细解释：

RabbitMQ 通过以下几种机制确保消息不丢失：

  1. 持久化机制：在 RabbitMQ 中，队列和消息可以设置为持久化。持久化队列会将消息写入磁盘，即使系统重启，消息也不会丢失。
  2. 确认机制：消费者在成功处理消息后会发送 ack 确认信号给 RabbitMQ。RabbitMQ 只有在收到确认信号后才会将消息从队列中移除。如果确认信号未收到，RabbitMQ 会重新投递消息，确保消息不会丢失。
  3. 镜像队列：镜像队列通过在多个节点间复制消息，确保在一个节点失败时，其他节点仍能存储消息，类似于 Redis 的主从复制，提供了高可用性。

5. RabbitMQ 如何保障消息正确发送? 如何确保消息正常消费? ​

重点

非常常考，答出确认机制和 ack 机制，基本就成功一大半了。事务机制可以锦上添花

先来说，如何保障正确发送。最常见的方式就是使用 发送者确认机制，我们可以通过客户端开启确认，可以使用 同步或者异步 等待 broker 告诉我们是否收到了消息。另一种就是 事务机制，事务机制类似于mysql的事务，保证消息的全部成功或者失败回滚。关于消息正常消费，就是 ack 机制，所有的消息在消费者如果消费成功之后，就会发送一个 ack的信号，broker 收到之后，就认为消息正常消费了，否则会进行重试等，继续找到消费者消费，

总结

  • 确认模式：生产者可以开启确认模式，通过 Channel.confirmSelect() 启用，并使用 Channel.waitForConfirms() 或异步的 Channel.addConfirmListener() 来接收 RabbitMQ 的确认信号。这可以保证消息在成功接收后被确认。如果 RabbitMQ 发生故障，生产者会收到未确认的消息，便于进行后续处理。

  • 事务模式：这种模式下，消息只有在事务提交后才被认为成功发送，类似于 MySQL 的事务机制。开启事务需要使用 channel.txSelect()，然后在发送消息时执行 commit。虽然事务模式提供了强一致性保证，但由于性能开销较大，一般仅在强一致性场景下使用。

技术漫游

Copyright@ 2024-2025 By 街蝉

本站访客数 人次 本站总访问量 次