vlambda博客
学习文章列表

前面我们跟大家聊了聊什么是消息中间件，以及哪些场景使用哪些消息中间件更加合适。

我们了解到RocketMQ是java语言开发的，我们能更深入的阅读源码了解它的底层原理，而且它具有优秀的消息中间件高级功能。再换个角度想，对于面试MQ来说，其实我们需要深入的了解一个中间件来与面试官聊，其他的中间件了解基本原理就可以了（后文会讲解）。

所以接下来我们就以RocketMQ为敲门砖，一点一点了解MQ的奥秘。

今天我们来聊一聊RocketMQ 的架构原理

先聊一聊RocketMQ是怎么实现高并发的呢，我们先从它的单机模式说起。

之前我们说过，单机的RocketMQ可以承受十万多的并发，那么这个时候如果业务上突然出现了几十万的并发量，这时候如何处理呢。

没关系，RocketMQ是支持集群化部署的，部署多台机器，每台机器承受十万的并发不就可以了吗。

其实这就是RocketMQ承受高并发的原理，当然，关于它是如何将流量分配到集群的每台机器上，这个问题以后会单独讲解，今天主要聊一聊总体的架构原理。

现在我们来看看，RocketMQ是如何持久化数据的。MQ收到大量消息后，这些消息是不能实时消费掉的，所以就会存在消息的积压，同时为了保证消息不丢失，所以持久化是很必要的。

而对于海量的消息，单独一台机器是存储不下的。退一步来讲，就算能够存储的下，一旦这台机器坏掉，数据就丢失了，无法保证消息的可靠性。

其实对于消息数据的持久化，和高并发的解决方案是类似的，看下图：

假设一共有一万条消息要发送给MQ，分散到10台机器，可能每台机器就会收到1000条左右的消息，这时候MQ会把发送到自己机器的消息保存到自己的磁盘里，其实就是数据的分布式存储。

所谓分布式存储就是把数据分散到多台机器存储，可以通过扩展机器存储海量数据。

在讨论这个问题之前，我们先引入一个新的概念，Broker。

Broker是RocketMQ的核心模块，负责接收并存储消息，同时提供Push/Pull接口来将消息发送给consumer。Consumer可选择从Master或者Slave读取数据。多个主/从组成Broker集群，集群内的Master节点之间不做数据交互。Broker同时提供消息查询的功能，可以通过MessageID和messageKey来查询消息。Borker会将自己的topic配置信息实时同步到NameServer。

一定有小伙伴会问，上边又出现了一个新名词NameServer，那什么是NameServer呢？不要急，下一章节会有介绍。

至于Producer（生产者）、Consumer（消费者），相信小伙伴们已经了解了，就是消息的生产服务和消费服务，不多做介绍。

了解了这些概念后我们再重新讨论我们的主题，RocketMQ挂掉了怎么办

Rocket对此的解决方案是Broker主从架构以及多副本策略，上边介绍Broker的时候我们也说了，它是有主从的，我们看下图：

Master Broker收到消息后会同步给Slave Broker，这样Slave Broker就有了一份副本数据，

这样，当RocketMQ挂掉了一个Broker，还有一份副本Broker可以继续提供服务，这就保证了系统的高可用性。

上边我们发现，Broker可以部署一个庞大的集群，还可以部署多个Slave做副本实现高可用，那么对于要调用MQ服务的系统来讲，是如何知道它应该访问那个Broker的呢？

这时候就要谈谈NameServer了。

NameServer可以看作是RocketMQ的注册中心，它也是可以独立部署集群的，它管理两部分数据：集群的Topic-Queue的路由配置；Broker的实时配置信息。其它模块通过NameServer提供的接口获取最新的topic配置和路由信息。

玩过Spring Cloud分布式系统的小伙伴们是不是觉得它很熟悉，没错它就是注册中心，功能类似于Euraka，每个Broker都会向它注册自己的信息，我们看下图：

 对于系统而言（无论是生产者还是消费者），要调用MQ服务，首先会去NameServer中获取路由信息，也会知道系统中有哪些Broker正在提供服务，从而确定自己应该访问哪台机器上的Broker。

RoketMQ的基本架构原理就是这样了，当然这只是个总体的架构，很多细节的东西都可以去深入探索，欢迎小伙伴们关注后续的文章，和HUC王子一起细嚼慢咽，探索消息中间件的乐趣吧。

往期文章推荐：