00-总结

消息的可靠传递

RocketMQ消息的延迟消息实现原理

• 存储阶段的“偷梁换柱”: 消息的主题和队列ID替换为系统内部主题 SCHEDULE_TOPIC_XXXX
• 调度与转发阶段: Broker内部有一个后台线程池（ScheduleMessageService），专门负责处理延迟消息,它会每隔1秒（或配置间隔）去对应的队列（SCHEDULE_TOPIC_XXXX 的特定队列）拉取消息,
  • 拉取到消息后，会检查消息的“预定投递时间”（存储时计算出的 当前时间 + 延迟时长）是否小于当前系统时间
  • 如果未到期：则重新挂起定时任务，等待下一轮（1秒后）检查。**
  • 如果已到期：Broker会利用原消息体，重新构建一条新消息。将新消息的主题（Topic）改回之前保存的 REAL_TOPIC（OrderTopic），队列改回 REAL_QID。**

RocketMQ消息的事务消息实现原理

两阶段提交（2PC） + 事务状态回查

• 第一步发送半消息：Broker收到后，不会立即将消息投递到消费者的队列，而是先将其暂存在一个特殊的内部主题 RMQ_SYS_TRANS_HALF_TOPIC 中。这条消息此时对消费者是不可见的，所以称为“半消息”（Half Message）。Broker成功存储半消息后，会向生产者返回消息发送成功的ACK
• 第二步执行本地事务：1生产者收到Broker的ACK后，开始执行本地数据库事务（比如更新订单状态为“已支付”）。生产者通过TransactionListener的executeLocalTransaction方法，向Broker提交事务二次确认状态。
• 第二步二次确认：生产者将本地事务状态（LocalTransactionState）发送给Broker，状态有三种：
  • COMMIT_MESSAGE：提交。Broker会将半消息从RMQ_SYS_TRANS_HALF_TOPIC取出，重新构建一条新消息，写入真实的业务Topic（如OrderTopic）的ConsumeQueue中。此时消费者才能看到并消费这条消息。
  • ROLLBACK_MESSAGE：回滚。Broker直接丢弃这条半消息，不投递给消费者。
  • UNKNOW：未知/或者超时，broker会自动回查/回调生产询问什么情况，这个就是事务状态回查。