教你设计一套高可用高并发、海量存储以及可伸缩的消息中间件生产架构（RocketMQ 必备）

到目前为止，我们已经基本掌握了MQ的相关核心工作原理，同时一起设计了消息路由中心 （消息中间件路由中心你会设计吗，不会就来学学）和 Broker 主从架构(消息队列Broker主从架构详细设计方案，这一篇就搞定主从架构)，现在如果让你基于它的基本原理去设计一套 MQ 的生产部署架构出来，你准备怎么去思考呢？

在这套架构中，你需要着重考虑的就是高可用问题，也就是说要保证整个系统在运行过程中，其中的任何一个环节宕机都不能影响整个系统。今天我们就来打卡如何设计一套高可用的消息中间件生产部署架构。

 

NameServer 集群化，保证路由高可用

首先，我们就是需要将NameServer 集群化部署，这里建议可以部署三台机器，这样可以充分的保证我们消息路由中心的可用性，哪怕其中的两台挂了，也还有一台 NameServer 在运行，这样就能保证我们 MQ 系统的稳定性。

前面我们也知道我们的NameServer 设计采用的是Peer-to-Peer 模式，即可以支持集群化部署的，每台机器是独立运行的，他们彼此直接不直接通信。

每台NameServer 机器都拥有所有的路由信息，包括所有的 Broker 节点信息、数据信息等 ，这样只要有一台 NameServer 存活就不会影响系统的稳定性。

所以，消息路由中心 NameServer 的集群化是我们整个MQ生产部署的第一步。

 

基于Dledger 的Broker主从架构部署

上面我们已经集群部署了消息路由中心 NameServer ，接下来我们看看怎么部署 Broker集群，应该用什么方式去部署。

昨天我们知道共有两种方式，一种是手工运维，这个会造成一段时间不可用时间，而且需要该配置重启之类的，比较麻烦，另一种就是基于 Dledger 技术实现自动切换故障部署。所以我们肯定就是选择基于 Dledger 主备自动切换的功能来进行生产架构的部署。

Dledger 技术是要求至少一个 Master Broker 带有两个 Slave Broker ，这样就是三个 Broker 共同组成一个 Group ，即作为一个分组来运行，如果，Master Broker 宕机，则可以从另外两个Slave Broker 选出一个作为Master Broker对外提供服务。

同时，Master Broker 还会将数据同步给所有Slsve Broker ，这样实现了一份数据在不同的节点上有多个副本。

 

Broker 是如何同 NameServer 通信的？

前面我们分享了Broker 会像所有 NameServer 发送心跳消息告知自己