RocketMQ - 消息中间件路由中心的架构原理

1. NameServer到底可以部署几台机器

要部署RocketMQ，就得先部署NameServer，那么NameServer到底可以部署几台机器呢？是一台机器还是可以部署多台机器，如果部署多台机器，他们之间是怎么协同工作的？

NameServer是支持部署多台机器的，也就是可以集群化部署，最主要的原因就是为了高可用性。因为NameServer是集群里面非常关键的一个角色，他要管理Broker的信息，别人都要通过他才知道要跟哪个Broker通信，所以没了他就会很麻烦。

那么如果NameServer就部署一台机器，一旦NameServer宕机了，就会导致整个RocketMQ集群出现故障；所以通常来说，NameServer一定会多机器部署，实现一个集群，起到高可用的效果，保证任何一台机器宕机，其他机器上的NameServer可以继续对外提供服务。

2. Broker是把自己的信息注册到哪个NameServer上？

有人可能会猜测，是不是这样，比如一共有10台Broker机器，2个NameServer机器，然后其中5台Broker会把自己的信息注册到1个NameServer上，另外5台Broker把自己的信息注册到另外一个NameServer上去？

答案是不对的，这样搞有一个最大的问题，如果1台NameServer上有5个Broker的信息，另外一个NameServer上有另外5个Broker的信息，那么此时任何一个NameServer宕机了，不就导致5个Broker的信息就没了吗？

所以说这种做法是不靠谱的，会导致数据丢失，系统不可用。

因此正确的答案是每个Broker启动的时候，都得向所有NameServer进行注册。也就是说每个NameServer都会有一份集群中所有Broker的信息。

3. 系统如何从NameServer获取Broker信息？

生产者和消费者需要知道集群里有哪些Broker，才能根据一定的算法挑选一个Broker去发送消息或者获取消息；有两种办法，第一种是NameServer会主动发送请求给所有的系统，告诉他们Broker信息，但是这种方法明显不靠谱，因为NameServer怎么知道要推送Broker信息给哪些系统呢？

第二种办法就是每个系统自己每隔一段时间，定时发送请求到NameServer去拉取最新的进群Broker信息；这个办法是靠谱的，没有什么明显的缺陷，所以RocketMQ中的生产者和消费者就是这样，自己主动去NameServer拉取Broker信息。
在这里插入图片描述
上图中的路由信息，大致可以理解为集群里的Broker信息以及其他相关的数据信息。

通过这些路由信息，每个系统就知道发送消息或者获取消息到哪台Broker上去进行了，这起到一个把消息路由到一个Broker上的效果，所以一般把这种信息叫做路由信息。

4. 如果Broker挂了，NameServer是怎么感知到的？

Broker启动之后会向NameServer注册自己的信息，每个NameServer都知道集群里有这么一台Broker的存在，然后各个系统从NameServer中也拉取到了Broker的信息，也知道集群里有这么一台Broker。

但是如果这个Broker宕机了呢？

要解决这个问题，靠的是Broker跟NameServer之间的心跳机制，Broker会每隔30秒给所有NameServer发送心跳，告诉每个NameServer自己还活着。

每次NameServer收到一个Broker得到心跳，就更新一下他最近一次心跳的时间。然后NameServer会每隔10秒运行一个任务，去检查一下各个Broker最近一次心跳时间，如果哪个Broker超过120秒都没发送心跳了，那么就认为这个Broker已经挂掉了。

5. 如果Broker挂了，系统是怎么感知到的？

如果Broker挂了，作为生产者和消费者的系统是怎么感知到的呢？难道必须得NameServer发送请求给所有系统通知他们吗？

这个是不现实的，之前已经说过了，NameServer去发送这个东西是非常不靠谱的。

但是如果NameServer没有及时的通知给那些系统，那么就会出现这样一种情况，刚开始集群里有10个Broker，各个系统从NameServer那里得知，都以为有10个Broker。

结果此时突然有一个Broker挂了，120s没有发送心跳给NameServer，NameServer是知道现在只有9个Broker了，但是此时其他系统是不知道只有9个Broker的，还以为有10个Broker，此时可能某个系统就会发送消息到那个已经挂掉的Broker上去，此时是绝对不可能成功发送消息的。
在这里插入图片描述
针对这种情况要怎么办？其实有两种办法解决