SpringBoot 场景开发多面手成长手册 小册笔记

整合RocketMQ

在开始运行 RocketMQ 之前，我们先思考一个实际的场景。

假设我们项目中有一个消息的生产者和消费者，它们连接到一个 RocketMQ 实例上，如下图所示。

随着业务规模的不断扩大，一个 RocketMQ 的实例已经有些不堪重负，于是我们需要将单机版的 RocketMQ 改为 RocketMQ 集群，此时我们不仅需要对 RocketMQ 扩容，还需要改变生产者和消费者的配置，让它们都连接到所有的 RocketMQ 实例上，如下图所示。

这样简单的扩容后会产生一个问题：如果 RocketMQ 的实例不断变动，那么消息的生产者和消费者会不断的修改配置，疲于应对 RocketMQ 集群的变动。

如何改善这种麻烦的现状呢？参照 SpringCloud 中服务注册与治理中心的思维，如果可以引入一个 RocketMQ 的注册中心，之后生产者和消费者都直接去连接注册中心，那是不是可以解决呢？

当然可以，RocketMQ 中就有一个对应的组件：NameServer 命名服务器，由这个 NameServer 来收集所有注册上线的 RocketMQ 实例（broker）。生产者和消费者只需要连接到 RocketMQ 的 NameServer 即可获得当前存活的 broker ，无需再因为 broker 扩容或者变动而改动配置。

如此了解下来，我们就能知道，RocketMQ 中包含一个 NameServer 和若干的 Broker ，由 NameServer 负责收集 Broker 的地址信息，Broker 负责实际的消息收发和存储工作。

既然是 NameServer 负责收集 Broker 的信息，那么先启动 NameServer 后启动 Broker 会更合理。