Java面试题整理5-RocketMQ

RocketMQ的延迟消息用过吗？怎么用？可以用在什么业务场景

延迟消息（Delay Message）：延迟消息指的是将消息发送到Broker后，在指定的时间后才可以被消费者接收到的消息。RocketMQ提供了延迟消息的机制，可以通过设置延迟时间来实现延迟消息的功能。适用于需要延迟触发或者需要定时推送的场景。
————————————————

RocketMQ的延迟消息通过设置消息的延迟级别（Delay Level）来实现，支持1秒~2小时的延迟时间。

具体来说，我们需要在发送消息时设置消息的延迟级别，然后通过RocketMQ提供的消息定时器来实现延迟处理。消息定时器会在消息发布后将消息存储在一个特殊的topic中，并记录该消息的发送时间和延迟时间。当消息达到指定的延迟时间后，RocketMQ会将该消息转发到目标topic中供消费者消费。

使用RocketMQ提供的延迟消息功能，可以实现一些需要对消息进行延时处理的场景。例如：

订单支付超时未完成，需要自动取消订单。

定时任务触发，例如每天凌晨执行某个批量操作等。

延时通知，例如活动开始前10分钟提醒用户等。

抢购等高并发场景，需要做流量削峰，将请求分散到一定的时间段内进行处理等。

RocketMQ事务消息使用场景

RocketMQ事务消息主要用于分布式事务的处理。在分布式事务中，一次操作需要跨越多个系统或者服务，如果在一个操作中出现异常，就可能导致数据不一致或者其他问题。而事务消息可以帮助我们解决这个问题，保证整个分布式事务的原子性。

具体来说，RocketMQ的事务消息是通过两阶段提交协议（Two-Phase Commit Protocol）来实现的。当我们发送事务消息时，RocketMQ会将消息状态设置为“prepared”（准备状态），并启动本地的事务。然后，消息将被发送到Broker，经过存储和备份后，Broker将响应“Transaction Prepared”（事务准备成功）结果，并等待下一步的指令。接下来，我们需要在本地执行事务操作，根据执行结果返回“Commit”或者“Rollback”指令。如果返回“Commit”指令，RocketMQ将把消息状态设置为“committed”（已提交状态），并通知消费者消费消息；如果返回“Rollback”指令，则将消息状态设置为“rollback”（回滚状态），并撤销消息。

使用RocketMQ的事务消息可以提高系统的可靠性和稳定性。它可以应用于一些需要保证多个系统或者服务之间数据一致性的场景，例如：

分布式订单处理：在跨服务的订单处理场景中，通过事务消息可以保证订单创建和支付等操作的原子性，避免出现数据不一致或者其他问题。

库存管理：在跨系统的库存管理场景中，通过事务消息可以保证减库存和增加销售额操作的原子性，避免出现数据不一致或者其他问题。

分布式任务调度：在分布式任务调度场景中，通过事务消息可以保证任务的原子性，例如某些任务需要在多个系统之间协作执行。

RocketMQ的事务消息可以帮助我们保证分布式事务的原子性和可靠性，但同时也会增加系统的复杂度和维护成本。因此，在使用事务消息时，需要根据具体场景和需求进行选择和优化。

MQ使用场景

消息队列（Message Queue，简称MQ）是一种异步通信的方式，在分布式系统中被广泛应用。MQ可以将应用程序之间的耦合度降到最低，使得系统更容易扩展和升级。以下是常见的MQ使用场景：

异步处理：将一些耗时的操作，例如发送邮件、短信、文件上传等操作，通过MQ进行异步处理，避免阻塞主线程。

流量削峰：在高并发场景下，通过MQ进行流量削峰，将请求分散到一定的时间段内进行处理，从而避免系统崩溃或者性能下降。

分布式系统集成：在分布式系统中，MQ可以作为各个服务之间通信的桥梁，实现微服务之间的解耦和调用。

数据可靠性和稳定性：在消息传递过程中，MQ可以通过持久化、备份等机制来保证数据的可靠性和稳定性，避免消息丢失或者重复消费。

业务解耦：在大型系统中，各个模块之间可能存在依赖关系，通过MQ可以实现模块之间的解耦，减少代码耦合度，提高系统的可维护性和可扩展性。

总之，MQ的使用场景非常广泛，可以帮助我们解决很多分布式系统中的问题，例如数据同步、任务调度、服务治理、日志处理等。但需要注意的是，在使用MQ时也需要考虑到一些潜在的问题，例如消息丢失、消息乱序、网络延迟等问题。

RocketMQ架构

RocketMQ 是由阿里开源的消息中间件，基于高性能的异步架构设计，支持高并发、高吞吐量和可扩展性。RocketMQ 的整体架构由 4 个核心组件组成：NameServer、Broker、Producer 和 Consumer。

NameServer
NameServer是RocketMQ的重要组件之一，负责管理Broker的状态信息和路由信息。在RocketMQ集群中，可以有多个NameServer节点，每个节点都有自己的服务地址和端口号，存储了所有Broker的地址信息，当Producer或Consumer需要发送或拉取消息时，会先连接到NameServer获取相应的Broker地址信息。

Broker
Broker是RocketMQ的另一个重要组件，它作为消息的存储和传输的中心节点，负责消息的接收、存储和转发。在RocketMQ集群中，可以有多个Broker节点，每个节点都有自己的服务地址和端口号，维护着自己所负责的Topic分区信息和消费者订阅关系。

Producer
Producer是RocketMQ消息生产者，用于发送消息到Broker，与Broker建立TCP连接，并将消息发送给指定的Topic。在发送消息时，Producer可以指定消息的发送模式（同步、异步或单向）和发送策略（同步或异步），确保消息的可靠性。

Consumer
Consumer是RocketMQ消息消费者，用于从Broker消费消息，与Broker建立TCP连接，并订阅指定的Topic和Tag，接收Broker推送的消息。

RocketMQ的架构设计非常灵活，可以根据实际需求进行扩展和定制。在多个生产者和消费者之间，RocketMQ可以通过集群方式来提供高可用性和负载均衡的支持；在多种发送模式和发送策略之间，RocketMQ可以根据业务需求来选择合适的方式来保证消息的可靠性和性能。因此，RocketMQ在大型分布式系统中被广泛使用，例如电商网站、金融系统、物流管理等领域。

RocketMQ工作流程

RocketMQ的工作流程可以分为以下几个步骤：

发送消息
Producer通过向NameServer查找Topic路由信息，确定要将消息发送给哪些Broker。然后，Producer通过TCP协议将消息发送给指定的Broker节点，Broker将消息存储在内存或磁盘中，并返回给Producer发送结果。

存储消息
Broker将从Producer接收到的消息存储在内存或磁盘中，以便后续的消费者进行消费。Broker会将消息持久化到磁盘上，以保证消息在故障后不会丢失。

消费消息
消费者通过向NameServer查找Topic路由信息，确定要从哪些Broker消费消息。然后，消费者向指定的Broker节点发起连接，并拉取该Topic的消息。在消息处理完成后，消费者将消息发送确认信息给Broker，Broker根据确认信息来更新消息队列的消费进度。

过滤消息
RocketMQ支持按照Tag和SQL表达式过滤消息，这样消费者可以只消费特定类型的消息，从而达到更精确的控制。

RocketMQ的工作流程非常简单明了，可以满足大规模分布式系统中海量消息的传输和处理需求。RocketMQ通过高效的异步架构设计来保障系统的高性能和可扩展性，通过多种机制来保证消息的可靠性和稳定性，满足大型应用系统的各类消息场景需求。

RocketMQ消息存储到内存还是磁盘，存储到磁盘会不会很慢

RocketMQ的消息存储既可以存储在内存中，也可以存储在磁盘上。默认情况下，RocketMQ会将消息存储在内存中，以实现更快的读写速度和更低的延迟。但是，为了保证消息的可靠性和避免因进程重启而导致消息丢失，RocketMQ也会定期将内存中的消息持久化到磁盘上，从而保证消息的持久化和可靠性。

在基于磁盘存储消息时，RocketMQ会采用顺序写入的方式，将消息逐条写入磁盘，并通过内存映射文件和缓存的方式提高读写速度。此外，RocketMQ还采用了读写分离的方式，将写操作和读操作分别放到不同的磁盘上，以提高系统的性能和稳定性。

总之，在RocketMQ中，消息的存储方式会根据实际需求和业务场景来灵活配置，可以选择将消息存储在内存中或磁盘上，以达到更高的性能、更低的延迟或更高的可靠性。当然，存储到磁盘上可能会有一定的IO延迟，但RocketMQ通过优化存储机制和使用多线程并发等策略，可以在保证可靠性的同时最大限度地提高性能。

RocketMQ发送消息的几种方式

在RocketMQ中，消息的发送方式可以分为以下几种：

同步发送（Sync Send）：
同步发送是最常用的一种方式，通过 send 方法发送消息并等待 Broker 的响应，直到 Broker 消息落盘后，返回发送结果。如果发送失败，会抛出异常。同步发送适用于对延时比较敏感的场景。

异步发送（Async Send）：
异步发送是通过 sendAsync 方法发送消息，该方法不会阻塞发送端线程，而是需要指定回调函数，在收到 Broker 响应之后会调用回调函数。如果发送失败，同样会通过回调函数通知发送结果。异步发送适用于对响应时间比较敏感，但又无法使用同步发送的场景。

单向发送（One-way Send）：
单向发送是通过 sendOneway 方法发送消息，该方法不关心发送结果，不等待 Broker 响应，因此性能最好，但不能保证消息是否到达。单向发送适用于日志记录等不需要返回结果的场景。

顺序发送（Orderly Send）：
顺序发送是指将消息按照一定的逻辑顺序发送到 Broker，确保消费者能够按照同样的顺序接收到消息。在 RocketMQ 中，顺序发送需要使用顺序生产者，并且消费者端也需要使用顺序消费者，才能够确保消息的顺序性。

总的来说，不同的发送方式适用于不同的场景，应该根据实际需求选择。

MQ消息队列分配算法

MQ消息队列分配算法主要有以下几种：

	1.轮询算法（Round Robin）
轮询算法是一种平均分配消息队列的算法，将消息队列均匀地分配给各个消费者，每个消费者依次获取消息队列中的消息。

	2.环形平均算法（Average Hashing）
环形平均算法通过在环上有序地依次分配消息队列给消费者，实现一人一次的策略。这种算法可以避免某些消费者空闲时间过长，但是可能导致某些消费者的消息积压较多。

	3.一致性哈希算法（Consistent Hashing）
一致性哈希算法通过计算消费者和消息队列的哈希值，将它们映射到一个环形空间上，并顺时针寻找消费者需要消费的消息队列进行消费。该算法可以避免因消费者数量变化而导致的负载不均衡问题。

	4.同机房消费算法（LocalForEachPartition）
同机房消费算法通过将消费者和消息队列的物理位置信息与网络拓扑结构相结合，选择距离最近的消费者进行消费。

Consumer拉取消息的模式

RocketMQ的Consumer可以以两种模式拉取消息：拉取模式（Pull Model）和推送模式（Push Model）。

拉取模式（Pull Model）：
在拉取模式下，Consumer主动向Broker请求获取消息。Consumer控制拉取的频率和拉取的数量。Consumer首先向Name Server获取Topic的路由信息，然后根据路由信息直接与Broker建立连接，通过向Broker发送拉取消息的请求，获取待消费的消息。拉取模式中的Consumer需要定期轮询Broker以获取新的消息。

推送模式（Push Model）：
在推送模式下，Broker将消息主动推送给Consumer。Consumer在启动时注册到Broker，然后Broker根据Topic和Consumer的订阅关系将消息推送给相应的Consumer。推送模式中的Consumer需要提供一个回调函数（MessageListener），当有新消息到达时，Broker会调用该回调函数将消息推送给Consumer。

推送模式相对于拉取模式具有更低的延迟，因为消息到达时会立即推送给Consumer，而不需要Consumer主动轮询。但是推送模式需要Consumer保持与Broker的长连接，以接收消息的推送，这对于Consumer的并发处理和容灾性能有一定的要求。

如何保证消息消费顺序

单一队列消费：
在创建Topic时，设置为只有一个队列（Queue），这样消息就会按照发送的顺序被顺序写入队列，并且Consumer也只会从该队列中拉取消息，从而保证了消息的顺序性。这种方式适用于只有一个消费者的场景。

消息按照Key进行有序分区：
在发送消息时，为每条消息设置一个Key，Key相同的消息将被分配到同一个队列中。Consumer按照队列的顺序消费消息，从而保证了同一个Key的消息被按顺序消费。这种方式适用于具有相同Key的消息需要被顺序处理的场景。

顺序消费模式（Orderly Consumption）：
RocketMQ提供了顺序消费模式，通过顺序消费模式可以保证相同的消息按照发送顺序被同一个消费者顺序消费。在使用顺序消费模式时，需要满足以下条件：

使用同一个Consumer Group。
Topic的消息被设置为顺序消息。
启用消息队列的顺序模式，即设置MessageModel.CLUSTERING。
消费者实现MessageListenerOrderly接口，该接口用于顺序消费消息。
需要注意的是，使用顺序消费模式可能会影响系统的并行度和吞吐量，因为同一队列上的消息只能被一个消费者线程处理。因此，在考虑消息顺序性的同时，还需要评估系统对并发处理和吞吐量的需求。