1、RocketMQ架构组成
由4大核心部分组成：NameServer、Broker、Producer以及Consumer。
可以看到RocketMQ的每一个模块都是集群部署的，这也是它高吞吐量、高可用的原因之一，可以支持多master-slave。
（1）NameSrv
主要负责对于数据源的管理，包括维持和Broker心跳，以及topic路由信息。其相比zk更加轻量级，zk要维护自身和所管理的服务节点的leader选举，所以不同的zk服务器间要通信，而NameSrv之间是相互独立，集群部署只为实现高可用，高吞吐。
但有一点需要注意，Broker向NameServer发心跳时， 会带上当前自己所负责的所有Topic信息，如果Topic个数太多（万级别），会导致一次心跳中，就Topic的数据就几十M，网络情况差的话， 网络传输失败，心跳失败，导致NameServ误认为Broker心跳失败。每个 Broker 在启动的时候会到 NameSrv 注册，Producer 在发送消息前会根据 Topic 到 NameSrv 获取到 Broker 的路由信息，Consumer 也会定时获取 Topic 的路由信息。
（2）Producer
消息生产者，负责产生消息，一般由消息业务系统产生消息。RocketMQ提供三种发送方式：同步、异步、单向（oneWay）
默认是同步发送，异步发送需要实现回调接口，单向只管发送而不需要等待服务端回应。异步发送方式如下：
producer.send(msg, new SendCallback() { @Override public void onSuccess(SendResult sendResult) { System.out.printf("%s%n",sendResult); } @Override public void onException(Throwable throwable) { throwable.printStackTrace(); } });
在发送消息时还可以自定义路由策略，RocketMQ提供了MessageQueueSelector，选择发送到哪个队列，比如把同一类型的消息都发往相同的 Message Queue：
SendResult sendResult=producer.send(msg, new MessageQueueSelector() { @Override public MessageQueue select(List<MessageQueue> list, Message message, Object o) { int key=o.hashCode(); int size = list.size(); int index = key%size; return list.get(index); } },"key_"+i); }
（3）Broker
消息中转角色，负责存储消息，转发消息。
Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接及心跳，在发送心跳时会将Topic信息注册到NameServer，底层的通信和连接都是基于Netty实现的。
所有消息都存储在commitLog上，每个topic对应多个队列，每个队列存储的是消息的地址和tag。
（4）Consumer
消费者，负责消费消息，支持PUSH和PULL两种获取消息的模式。
Pull：拉取型消费者（Pull Consumer）主动从消息服务器拉取信息，只要批量拉取到消息，用户应用就会启动消费过程，所以 Pull 称为主动消费型。
Push：推送型消费者（Push Consumer）封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型，但从实现上看还是从消息服务器中拉取消息，不同于 Pull 的是 Push 首先要注册消费监听器，当监听器处触发后才开始消费消息。
RocketMQ也支持集群消费和广播消费两种消费模式。
集群消费：默认情况下就是集群消费，该模式下一个消费组共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。
广播消费：广播消费消息会发给消费者组中的每一个消费者进行消费。