RocketMQ的架构原理
了解RocketMQ的时候，首先我们需要看下RocketMQ大体上是怎么运行的，也就是它的基本原理，然后了解下RocketMQ是如何承载高并发访访问的，如何存储海量消息。
RocketMQ集群化部署
首先，如果RocketMQ部署在一台服务器上，即使这台服务器的性能再好，一般来说也就能支撑10w+的并发访问。
那么此时如果有大量的系统都要往RocketMQ里高并发的写入消息，可能每秒达到几十万请求，这个时候如何处理？
RocketMQ是可以集群部署的，部署在多台服务器上，假设每台服务器都可以抗10w并发，这个时候，我们只需要让这几十w的请求分散到多台机器上就可以了，让每台服务器承受的QPS不超过10w就可以了。
这就是RocketMQ通过集群化部署来抗下高并发的主要原理，具体的流量分散、处理后面再详细讲。
RocketMQ存储海量消息
MQ收到大量消息后，不一定会立马被消费掉，所以一般来说，MQ需要先把消息存储在本地磁盘，然后等待消费者来获取消息去处理。
那么此时，MQ就得存储大量的消息，可能是几百万条，几千万条，甚至是上亿条，这么多消息在一台服务器上肯定是没法存储的，所以此时就需要通过分布式存储海量消息。
其实生产者会把消息分散的发送给多台不同的服务器上，假设有10w条消息，分散发给10台服务器，平均每台服务器也就接收到1w条消息，每台服务器上部署的RocketMQ进程一般称为Broker，每个Broker都会收到不同的消息，然后把这些消息存储在本地磁盘文件中。
所以本质上Rocket存储海量信息的机制就是分布式存储。
高可用性
上面讲到消息是分别存储在不同的Broker上的，那如果某个broker宕机了，是否会出现数据丢失的问题？应该如何解决？
此时就提到了RocketMQ的Broker主从架构以及多副本策略。
Broker分为Master和Slave两个角色，生产者将消息发送到Master Broker后，Master Broker会同步给Slave Broker，这样同一条消息在RocketMQ集群中就存在两个副本了，这个时候如果任何一个Master Broker出现故障或者宕机了，那么还有一个Slave Broker上有一份数据副本，确保了数据不丢失，还可以继续对外提供服务，确保了MQ的高可用性。
数据路由
对于这么多Broker，生产者和消费者是怎么知道去那个Broker发消息或消费消息呢？
RocketMQ中，有一个NameServer概念，NameServer也是可以独立部署在多台服务器上的，所有的Broker都会去NameServer注册自己，这样由NameServer统一的管理集群的Broker路由。
对于生产者来说，只需要去NameServer上获取路由信息，将消息发送到Broker上，
对于消费者来说，也是去NameServer上获取路由信息，然后找到对应的Broker消费消息。
这就是RokcetMQ的一个基本的架构原理。
