12 RocketMQ高可用的生产部署架构

Posted 2021-07-22 鮀城小帅

1.NameServer采用集群化部署，保证高可用

第一步，让NameServer集群化部署，初步可以部署在三台机器上，可以充分保证NameServer作为路由中心的可用性，哪怕挂掉两台也能有一台正常运行，从而保证MQ系统的稳定性。

2.基于Dledger的Broker主从架构部署

RocketMQ4.5版本之前的手动运维会导致系统的不可用。所以还是采取4.5版本后基于Dledger协议的自动主备切换的功能，来实现自动让Slave切换为Master的功能。

Dledger要求至少一个Master带两个Slave，这样就需要有三个Broker组成一个Group，也就是作为一个分组来运行。一旦Master宕机，他就可以从剩余的两个Slave中选举出来一个新的Master对外提供服务。

以上是主从架构部署后注册到NameServer的架构图。

3.Broker和NameServer之间的通信问题

这里要明确一点，在RocketMQ中，采用的是TCP长连接进行通信。

也就是说，Broker会跟每个NameServer都建立一个TCP长连接，然后定时通过TCP长连接发送心跳请求过去。

所以各个NameServer就是通过跟Broker建立好的长连接不断收到心跳包，然后定时检查Broker有没有120s都没发送心跳包，来判定集群里各个Broker到底挂掉了没有。

4.生产者与消费者的集群部署

使用MQ的系统，也就是生产者和消费者的部署并不在MQ的考虑范围内，一旦生产或消费系统宕机，那么整个流程就断开了，不能保证高可用性。

有鉴于此，无论作为生产者还是消费者的系统，都应该多机器集群化部署，保证它自己本身作为生产者或者消费者的高可用性。

如图，在多台机器上部署生产者系统，任何一台机器上的生产者挂了，其他机器上的生产者系统可以继续运行。

而消费者系统也是集群化部署的，如果一台机器上的消费者系统挂了，其他机器上的消费者系统应该是可以继续运行的。

5.MQ的核心数据模型：Topic

生产者和消费者往MQ里写入消息和获取消息还需要清楚以下问题：

MQ中的数据模型是什么？你投递出去的消息在逻辑上到底是放到哪里去的？是队列吗？还是别的什么呢？

重要概念，Topic，这是MQ中的核心数据模型。Topic，是一个数据集合的意思，不同类型的数据你的放不同的Topic里去。比如：订单信息的数据集合生产时，就需要建一个叫topic_order_info这样的Topic，然后把订单信息放进去。而消费者系统就从这样的Topic里去取消息进行消费。

6.Topic在Broker集群里的存储方式

一个Topic的数据集合采取分布式存储的方式分发存放在多态机器上的。

比如：一个Topic里有1000W条数据，此时有2台Broker，那么就可以让每台Broker上都放500万数据。

Topic与NameServer，每个Broker在进行定时的心跳回报给NameServer的时候，都会告诉NameServer自己当前的数据情况，比如有哪些Topic的哪些数据在自己这里，这些信息都是属于路由信息的一部分。

7.生产者系统是如何将消息发送给Broker的？

生产者在发送消息之前，要先有一个Topic，然后在发送消息的时候就可以执行要发送到哪个Topic里面去。

在知道要发送的Topic之后，可以跟NameServer建立一个TCP长连接，然后定时从它那里拉取到最新的路由信息，包括集群里有哪些Broker，集群里有哪些Topic，每个Topic都存储在哪些Broker上。

（1）生产者如何选择Broker来进行分发

生产者系统投递消息的Topic分发的方式是，根据负载均衡算法，从里面选择一台Broker机器出来，比如round robine轮询算法，或者是hash算法来实现。

（2）小结

选择一台Broker之后，就可以跟那个Broker也建立一个TCP长连接，然后通过长连接向Broker发送消息即可。

生产者一定是投递消息到Master Broker的，然后Master Broker 会同步数据给他的Slave Brokers，实现一份数据多分副本，保证Master故障的时候数据不丢失，而且可以自动把Slave切换为Master提供服务。

8.消费者从Broker上拉取消息的原理

消费者系统与生产者系统的原理是类似的，也会跟NameServer建立长连接，然后拉取路由信息，接着找到自己要获取消息的Topic在哪几台Broker上，就可以跟Broker建立长连接，从里面拉取消息了。

注意：消费者系统可能会从Master Broker拉取消息，也可能从Slave Broker拉取消息，都有可能，一切看具体情况。

9.整体架构：高可用、高并发、海量消息、可伸缩

（1）高可用

整套架构中NameServer采取集群化部署，每台机器都有完整的路由信息，随便一台NameServer机器宕机都不会影响整体注册服务。

Broker采用Master-Slave主从架构，集群中的Master挂了会基于Dledger协议实现自动Slave切换为Master。

基于以上两点可实现完全高可用。

（2）高并发

该架构下，采取多个Master的集群，可以抗下高并发。比如Topic要发起每秒10万QPS的写入，那么只要分散在2台Broker上，实际上每个Broker会承载5万QPS写入，也就是说高并发场景下的10万QPS可以分散到多台Broker上扛下来。

（3）海量消息

由于MQ的Topic中的数据都是分布式存储的，每个Topic的数据都是存储在多台Broker机器上的，用集群里多个Master Broker就足以存储海量的消息。

（4）可伸缩

该架构具备伸缩性，如果要抗更高的并发，存储更多的数据，可以在集群里加入更多的Broker机器，这样就可以线性扩展集群了。