RocketMQ基础概念剖析

上图中，RocketMQ被标识为了一个单点，但事实上肯定不是如此，对于可以随时横向扩展的服务来说，生产者向MQ生产消息的数量也会随之而变化，所以一个合格成熟的MQ必然是要能够处理这种情况的;而且MQ自身需要做到高可用，否则一旦这个单点宕机，那所有存储在MQ中的消息就全部丢失且无法找回了。

所以在实际的生产环境中，肯定是会部署一个MQ的集群。而在RocketMQ中，这个“实例”有个专属名词，叫做Broker。并且，每个Broker都会部署一个Slave Broker，Master Broker会定时的向Slave Broker同步数据，形成一个Broker的主从架构。

那么问题来了，在微服务的架构中，部署的服务也存在多实例部署的情况，服务之间相互调用是通过注册中心来获取对应服务的实例列表的。

拿Spring Cloud举例，服务通过Eureka注册中心获取到某个服务的全部实例，然后交给Ribbon，Ribbon联动Eureka，从Eureka处获取到服务实例的列表，然后通过负载均衡算法选出一个实例，最后发起请求。

同理，此时MQ中存在多个Broker实例，那生产者如何得知MQ集群中有多少Broker实例呢?自己应该连接哪个实例?

首先我们直接排除在代码里Hard Code，具体原因我觉得应该不用再赘述了。RocketMQ是如何解决这个问题呢?这就是接下来我们要介绍的NameServer了。

NameServer

NameServer可以被简单的理解为上一小节中提到的注册中心，所有的Broker的在启动的时候都会向NameServer进行注册，将自己的信息上报。这些信息除了Broker的IP、端口相关数据，还有RocketMQ集群的路由信息，路由信息后面再聊。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!