weixin_42118323的博客

RocketMQ 在发送事务消息时，会先发送一条“half 消息“也叫半消息，半消息会被保存在 Broker 端的事务消息日志中，这个消息此时还不能被消费者消费，半消息发送成功后，会执行本地事务，最终根据本地事务的执行结果来确定是否要提交该事务消息，若本地事务执行成功，则通知 Broker 提交事务消息，让该消息可以被消费者消费，否则就会通知 Broker 删除该消息，从而保证该消息不会被消费者消费。MQ 的消费模式有三种，分别是 Push 推模式、Pull 拉模式以及 5.0 版本推出的 POP 模式。

上一篇我们分享了 RocketMQ 消息重试的一些基本原理，本篇我们基于 Spring Boot 整合 RocketMQ 来分享一下 RocketMQ 消息基于手动提交的案例，在分享手动进行消息 ACK 中也会分享消息重试的使用。

由于网络延迟、服务宕机等不确定因素，在使用 RocketMQ 时可能会出现消息发送失败和消息消费失败的情况，RocketMQ 研发团队也考虑到了这个问题，RocketMQ 内部使用了生产者和消费者的消息重试机制，来防止消息丢失问题，本篇我们来分享一下关于 RocketMQ 的消息重试机制。

事务消息使用 rocketMQTemplate的sendMessageInTransaction 方法发送，返回结果为TransactionSendResult对象，该对象中包含了事务发送的状态、本地事务执行的状态等，生产者代码的核心逻辑是向 RocketMQ 发送事务消息，并执行本地事务，最后将本地事务的执行结果通知到 RocketMQ，返回结果为TransactionSendResult对象，该对象中包含了事务发送的状态、本地事务执行的状态等。将二阶段提交和本地事务绑定，实现全局提交结果的一致性。

当我们的消费者集群重新加入了节点的时候，这个时候就会发生重平衡，重平衡之前的队列可能属于 A 节点来消费，假设重平衡之后该队列属于 B 节点来消费，此时节点 A 就需要把自己加在 Broker 上的锁解锁，让节点 B 来申请锁，如果此时节点 A 拉取了消息正在消费但是还没有提交 ACK，而节点 B 马上又去拉取消息消费，此时就可能会出现重复消费的情况，那如何避免这种情况呢，这时就需要通过处理队列上的锁来判断了，只有当处理队列上的锁释放了，其他节点才可以正常消费该消息，这样就避免了消息重复消费。

需要注意的是 RocketMQ 的延迟消息使用的是 delayLevel 延迟级别来表示的，并不是直接使用时间，例如：delayLevel = 1 延迟时间为 1秒，delayLevel = 2 延迟时间为 5秒，delayLevel = 3 延迟时间为 10秒，delayLevel = 4 延迟时间为 30秒，以此类推。上一篇我们分享了 Spring Boot 整合 RocketMQ 完成单向消息、同步消息、异步消息发送的过程，本篇我们来分享一下 RocketMQ 延时消息的使用。

在消息中间件领域中 RocketMQ 是一种非常常见的消息中间件了，并且是由阿⾥巴巴开源的消息中间件 ，本篇简单分享一下 Spring Boot 项目集成 RocketMQ 的过程。

消息队列是一种用于在分布式系统中进行通信的技术，它是一种存储和转发消息的中间件，可以用于将应用程序之间的通信解耦，从而实现高效的异步通信，消息队列允许发送者将消息发送到队列中，而接收者则可以从队列中获取消息并进行处理，这种方式可以帮助系统实现高可用性、高性能、松耦合和可伸缩性，消息队列通常包括生产者（发送消息的应用程序）、消费者（接收消息的应用程序）和队列（存储消息的缓冲区），常见的消息队列有 Kafka、RocketMQ、RabbitMQ、Redis 等。如有不正确的地方欢迎各位指出纠正。