基本概念
ProducerGroup
通常具有同样属性（处理的消息种类-topic、以及消息处理逻辑流程—分布式多个客户端）的一些producer可以归为同一个group。在事务消息机制中，如果某条发送某条消息的producer-A宕机，使得事务消息一直处于PREPARED状态并超时，则broker会回查 同一个group的其他producer，确认这条消息应该commit还是rollback。
ConsumerGroup
具有同样逻辑消费同样消息的consumer，可以归并为一个group。同一个group内的消费者，可以共同消费（CLUSTERING）对应topic的消息，达到分布式并行处理的功能。
Topoic
消息的逻辑管理单位。
Queue
消息的物理管理单位。一个Topic下可以有多个Queue，Queue的引入使得消息存储可以分布式集群化，具有了水平扩展的能力。
消费进度管理
RocketMQ的broker端，不负责推送消息，无论消费者是否消费消息，都将消息存储起来。谁要消费消息，就向broker发请求获取消息，消费记录由consumer来维护。RocketMQ提供了两种存储方式来保留消费记录：一种是保留在consumer所在的服务器上；另一种是保存在broker服务器上。用户还可以自己实现相应的消费进度存储接口。
默认情况下，采用集群消费（CLUSTERING），会将记录保存在broker端；而采用广播消费（BROADCASTING）则会将消费记录保存在本地。
顺序消息
用户实现MessageQueueSelector为某一批消息（通常是有同样的唯一的标示ID），选择同一个Queue，则这一批消息的消费将是顺序消费（并由同一个consumer完成消费）。
事务消息
这样的消息有多个状态，并且其发送是两阶段的。第一个阶段发送PREPARED状态的消息，此时consumer是看不见这种状态的消息的，发送完毕后回调用户的TransactionExecutor接口，执行相应的事务操作（如数据库），当事务操作成功时，则对此条消息返回commit，让broker对该消息执行commit操作，成为commit状态的消息对consumer是可见的。
基本原理
总览
RocketMQ以Topic来管理不同应用的消息。对于生产者而言，发送消息是，需要指定消息的Topic，对于消费者而言，在启动后，需要订阅相应的Topic，然后可以消费相应的消息。Topic是逻辑上的概念，在物理实现上，一个Topic由多个Queue组成，采用多个Queue的好处是可以将Broker存储分布式化，提高系统性能。[pagebreak][pagebreak]
RocketMQ中，producer将消息发送给Broker时，需要制定发送到哪一个队列中，默认情况下，producer会轮询的将消息发送到每个队列中（所有broker下的Queue合并成一个List去轮询）。
对于consumer而言，会为每个consumer分配固定的队列（如果队列总数没有发生变化），consumer从固定的队列中去拉取没有消费的消息进行处理。
Producer
Producer端（属于client）的逻辑概述：
producer端的逻辑都比较简单，将消息发送到某个Queue中即可，具体发送到那个Queue可以由用户控制（MessageQueueSelector接口），默认情况下，将轮询方式选择Queue。在producer端，会从NameServer将所有Broker的Topic及对应的Queue信息（即：TopicRoute信息）拉取到本地，然后根据<brokerName， queueId>组建成一个List。因此在MessageQueueSelector，可以看到所有的Queue信息。
RocketMQ将topic的消息以多个Queue来管理，使得其较为容易的就可以进行水平扩展，提供系统吞吐力。这样分布带来的问题，就是从全局上不能做到顺序性（很多时候也并不需要全局上的顺序性）。
RocketMQ提到支持顺序消息，实际上是指基于Queue级别的顺序。用户将某些需要满足顺序的一批消息（比如电商某个订单号的一系列后续操作、比如数据库的某个主键的insert、delete、update等操作）发送到固定的某个Queue中，则从这个Queue消费消息的consumer，针对这一批消息是顺序消费。
问题1：针对顺序消息的队列，是否可以做到不停服务下的集群动态扩展？
Consumer
consumer逻辑稍微复杂一点。初步思考，consumer端至少需要处理：
1、 消息的获取
2、 offset（消费进度）的管理与存储
3、 集群消费模式下，Queue的分配问题（rebalance）
RocketMQ对外提供了两种不同形式的Consumer：PushConsumer和PullConsumer。顾名思义，对于PullConsumer而言，用户需要主动调用相应的接口去拉取未消费的消息。对于PushConsumer而言，用户提供消息处理的CallBack，有未曾消费的消息时，会主动回调这个CallBack来处理消息。虽从用户角度而言，Consumer存在主动（pull）和被动（push），但RocketMQ本身的broker端仅仅保存所有的消息，并不负责push消息，因此PushConsumer的底层实现也是有一个长连接主动去broker上拉取未消费的消息，然后回调用户的callback逻辑。