RocketMQ事务消息是如何实现的？

大家好，我是锋哥。今天分享关于【RocketMQ事务消息是如何实现的？】面试题。希望对大家有帮助；

RocketMQ事务消息是如何实现的？

1000道 互联网大厂Java工程师 精选面试题-Java资源分享网

RocketMQ 事务消息的实现是通过 分布式事务 的机制来保证消息的可靠性和一致性，主要通过 三阶段提交（Three-Phase Commit）来实现。下面详细介绍 RocketMQ 事务消息的实现过程：

1. 事务消息的概述

RocketMQ 提供了事务消息的功能，用于处理消息的 最终一致性，保证消息在发送和消费过程中的原子性。如果消息发送成功但消费者无法正常处理，可以通过重试机制和事务补偿来确保最终一致性。

2. 事务消息的实现机制

RocketMQ 事务消息的实现分为三个阶段：

阶段 1：消息发送（事务消息的发送阶段）

• 在发送消息时，生产者会先发送一条 半消息（Half Message） 到消息队列，这条消息处于 暂挂状态，此时消息并未真正被消费者消费。
• 在这一步中，消息会附带上一个事务标识，以便后续处理。

阶段 2：执行本地事务（事务执行阶段）

• 消息发送到 Broker 后，生产者会执行本地事务逻辑，比如数据库操作、调用外部接口等。
• 在执行本地事务时，生产者会返回一个 事务状态（COMMIT、ROLLBACK、UNKNOWN）来告知 Broker 事务的执行结果：
  • COMMIT：本地事务成功，消息可以提交给消费者。
  • ROLLBACK：本地事务失败，消息会被回滚，消费者无法消费。
  • UNKNOWN：事务未完成，需要进一步检查。

阶段 3：消息提交或回滚（事务消息的补偿检查阶段）

• 在事务执行完成后，生产者会向 RocketMQ Broker 发送事务状态的反馈：
  • 如果生产者执行了本地事务，并返回了 COMMIT，Broker 会将半消息变为正常消息，并允许消费者消费。
  • 如果返回了 ROLLBACK，Broker 会丢弃该消息，确保消费者无法消费。
  • 如果生产者返回 UNKNOWN，Broker 会在一定时间后发起 事务状态检查请求，这时 Broker 会询问生产者该消息的事务状态。如果生产者在事务状态检查时依然没有给出明确结果，Broker 会重试这个检查操作直到得到结果。

3. 事务状态检查

RocketMQ 为了确保事务的最终一致性，设计了一个 事务状态回查机制：

• 当生产者未能返回明确的事务状态（例如，因网络问题等）时，Broker 会定期向生产者发起 事务状态回查。
• 生产者需要在回查接口中提供事务状态（COMMIT 或 ROLLBACK），并根据业务逻辑返回当前事务的最终处理结果。

4. 事务消息的发送过程

• 生产者通过 sendMessageInTransaction() 方法发送事务消息。
• 在 sendMessageInTransaction() 调用中，消息被发送到 Broker 后，生产者会执行本地事务（例如，数据库更新、调用外部接口等）。
• 如果本地事务执行成功，则返回 COMMIT 事务状态，消息就会正常提交。
• 如果本地事务失败，则返回 ROLLBACK，消息会被回滚。
• 如果状态未知，则返回 UNKNOWN，并等待事务状态回查。

5. 事务回查接口

生产者需要实现一个 事务回查接口 (TransactionCheckListener)，当消息处于未知状态时，Broker 会调用该接口来确认事务的最终状态。接口方法通常如下：

public interface TransactionCheckListener {
    // 用于回查事务状态
    public TransactionStatus checkLocalTransaction(Message msg);
}

6. 事务消息的总结

• 事务消息通过半消息 + 本地事务 + 事务回查的机制，确保了消息在发送与消费过程中能够达到最终一致性。
• RocketMQ 事务消息的优势在于它能够保证 异步消息传递过程中的一致性，特别适用于需要保证数据一致性和可靠性的场景。
• 这种机制对于实现金融、电商等场景中的分布式事务非常有用。

7. 使用 RocketMQ 事务消息时需要注意

• 事务消息的性能开销较大，因为涉及到消息发送、事务执行、状态回查等步骤。它适合用于那些必须保证一致性的场景，不建议用于高吞吐量的消息场景。
• 回查逻辑可能会导致事务的不确定性，因此需要确保回查的实现逻辑能够正确判断事务状态。

总体来说，RocketMQ 事务消息通过三阶段提交机制，确保了消息在高并发、分布式系统中的一致性和可靠性。