你懂RocketMQ 的架构原理吗？
前言
前面我们跟大家聊了聊什么是消息中间件，以及哪些场景使用哪些消息中间件更加合适。
我们了解到RocketMQ是java语言开发的，我们能更深入的阅读源码了解它的底层原理，而且它具有优秀的消息中间件高级功能。再换个角度想，对于面试MQ来说，其实我们需要深入的了解一个中间件来与面试官聊，其他的中间件了解基本原理就可以了（后文会讲解）。
所以接下来我们就以RocketMQ为敲门砖，一点一点了解MQ的奥秘。
今天我们来聊一聊RocketMQ 的架构原理
RocketMQ是如何承受高并发的呢？
先聊一聊RocketMQ是怎么实现高并发的呢，我们先从它的单机模式说起。
之前我们说过，单机的RocketMQ可以承受十万多的并发，那么这个时候如果业务上突然出现了几十万的并发量，这时候如何处理呢。
没关系，RocketMQ是支持集群化部署的，部署多台机器，每台机器承受十万的并发不就可以了吗。
其实这就是RocketMQ承受高并发的原理，当然，关于它是如何将流量分配到集群的每台机器上，这个问题以后会单独讲解，今天主要聊一聊总体的架构原理。
RocketMQ是如何存储大量消息数据的呢？
现在我们来看看，RocketMQ是如何持久化数据的。MQ收到大量消息后，这些消息是不能实时消费掉的，所以就会存在消息的积压，同时为了保证消息不丢失，所以持久化是很必要的。
而对于海量的消息，单独一台机器是存储不下的。退一步来讲，就算能够存储的下，一旦这台机器坏掉，数据就丢失了，无法保证消息的可靠性。
其实对于消息数据的持久化，和高并发的解决方案是类似的，看下图：
假设一共有一万条消息要发送给MQ，分散到10台机器，可能每台机器就会收到1000条左右的消息，这时候MQ会把发送到自己机器的消息保存到自己的磁盘里，其实就是数据的分布式存储。
所谓分布式存储就是把数据分散到多台机器存储，可以通过扩展机器存储海量数据。
如果RocketMQ挂掉了怎么办?
在讨论这个问题之前，我们先引入一个新的概念，Broker。
Master Broker收到消息后会同步给Slave Broker，这样Slave Broker就有了一份副本数据，
这样，当RocketMQ挂掉了一个Broker，还有一份副本Broker可以继续提供服务，这就保证了系统的高可用性。
对于系统而言（无论是生产者还是消费者），要调用MQ服务，首先会去NameServer中获取路由信息，也会知道系统中有哪些Broker正在提供服务，从而确定自己应该访问哪台机器上的Broker。
RoketMQ的基本架构原理就是这样了，当然这只是个总体的架构，很多细节的东西都可以去深入探索，欢迎小伙伴们关注后续的文章，和HUC王子一起细嚼慢咽，探索消息中间件的乐趣吧。
往期文章推荐：
我的博客即将同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=2dl7u9oadykgw