RocketMQ

当Broker在启动的过程中，Broker就会往NameServer注册自己这个Broker的信息，这些信息就包括自身所在服务器的ip和端口，还有就是自己这个Broker有哪些topic和对应的队列信息，这些信息就是路由信息，后面就统一称为路由表。

选择 RocketMQ 或 Kafka 主要取决于具体的业务需求、系统要求以及团队的技术栈偏好。如果需要处理具有复杂业务逻辑的事务性消息，或需要精确控制消息顺序和定时发送的功能，RocketMQ 可能是更合适的选择。

Kafka 与其他两个主流的中间件 RabbitMQ 和 RocketMQ 相比，Kafka 最大的优势就是高吞吐量。

RocketMQ 是阿里自研的国产消息队列，目前已经是 Apache 的顶级项目。和其他消息队列一样，它接受来自生产者的消息，将消息分类，每一类是一个 topic，消费者根据需要订阅 topic，获取里面的消息。

通过学习 ONS 的设计方式，我对于 RocketMQ 的客户端原理有了进一步了解，也实现了公司内部使用的 RocketMQ SDK 。

在业务使用消息中间件的过程中，提出了开发测试环境项目多版本隔离的诉求。本文将介绍我们基于 RocketMQ 如何实现的多版本环境隔离。

RocketMQ事务消息是一种支持分布式事务的消息模型，将消息生产和消费与业务逻辑绑定在一起，确保消息发送和事务执行的原子性，保证消息的可靠性。

当消息达到RocketMQ服务端之后，为了能够保证服务端重启之后消息也不丢失，此时就需要将消息持久化到磁盘。

针对物理机部署RocketMQ运维、迁移、扩缩容费时费力，操作复杂；业务增加以后，资源无法弹性，手动扩缩容实时性差；底层资源利用率不高，用户资源隔离和流量的管控需要额外投入等问题。

每个进程都有自己独立的内存空间，当一个进程崩溃时，其内存空间会被操作系统回收，不会影响其他进程的内存空间。这种进程间的隔离性保证了一个进程崩溃不会直接影响其他进程的执行。

本文解决了在 RocketMQ 2.1.0 版本以后，无法简单使用多个 @RocketMQTransactionListener​ 的问题。通过引入事务消息处理接口 TransactionMessageHandler，我们将原有的事务处理器改造成了一个分发器，使得在 DailyMart 项目中可以轻松处理多事务消息的场景。

针对物理机部署RocketMQ运维、迁移、扩缩容费时费力，操作复杂；业务增加以后，资源无法弹性，手动扩缩容实时性差；底层资源利用率不高，用户资源隔离和流量的管控需要额外投入等问题。

ScheduleExecutorService 因其简单易用且性能优异，在各大开源中间件项目（比如 RocketMQ、MetaQ、Canal 等）中被广泛的使用。

消息不丢失、不重复是消息队列的基本要求，但这个基本要求还是很难满足的。消息丢失这个要求，主流消息队列通过消息重试和消息持久化的方式可以满足。但消息重试也同时带来了消息重复的可能性，主流消息队列在解决重复消息的问题上并没有现成的方案，对不允许重复消费的场景，需要开发人员在消费端做幂等处理。

本文将通过RocketMQ作为例子，来扒一扒什么情况下会导致重复消费。