RocketMQ基本概念及原理介绍

基本概念

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端至少须要处理：

一、 消息的获取

二、 offset（消费进度）的管理与存储

三、 集群消费模式下，Queue的分配问题（rebalance）

RocketMQ对外提供了两种不一样形式的Consumer：PushConsumer和PullConsumer。顾名思义，对于PullConsumer而言，用户须要主动调用相应的接口去拉取未消费的消息。对于PushConsumer而言，用户提供消息处理的CallBack，有不曾消费的消息时，会主动回调这个CallBack来处理消息。虽从用户角度而言，Consumer存在主动（pull）和被动（push），但RocketMQ自己的broker端仅仅保存全部的消息，并不负责push消息，所以PushConsumer的底层实现也是有一个长链接主动去broker上拉取未消费的消息，而后回调用户的callback逻辑。