RocketMq是一个由阿里巴巴开源的消息中间件，脱胎去阿里每部使用的MetaQ，在设计上借鉴了Kafka。

2012年开源，2017年成为apache顶级项目。

rocketmq的概念模型

入门一项新技术，首先认识它的核心概念。

这三者是RocketMq中最最基本的概念。Producer是消息的生产者。Consumer是消息的消费者。消息通过Topic进行传递。Topic存放的是消息的逻辑地址。

具体来说是Producer将消息发往具体的Topic。Consumer订阅Topic，主动拉取或被动接受消息。

实际上，Topic还需要拆封出更多概念

这张图里有两个生产者，ProducerA和ProducerB。定义了两个Topic-TopicA和TopicB。ProducerA会发送两种消息。

TopicA有3个MessageQueue，MessageQueue记录的是消息的物理存储地址（在consumelog里的位置），分布在两个broker上。Broker是一个集群部署架构上的概念，可以理解为对应的物理机器。最右边是ConsumerGroup，每一组下又有多个Consumer，实际上也就是启动的用来消费的JVM。一个Consumer可以订阅多个不同的Topic。这里我有话要说，虽然从代码层面上支持这种订阅。但是强烈不建议一个Consumer订阅多个不同的Topic。推荐用法是一组ConsumerGroup只订阅一种Topic。

另外多组ConsumerGroup之间，对于同一个Topic是广播订阅的。（翻译一下就是说：Topic的一条消息会广播给所有订阅的ConsumerGroup，就是每个ConsumerGroup都会收到），但是在一个ConsumerGroup内部给个Consumer是负载消费消息的，（翻译一下就是：一条消息在一个group内只会被一个Consumer消费）

存储模型

下面看看Rocketmq的消息实际是怎么存储的？

左边的是CommitLog。这个是真正存储消息的地方。可以看出RocketMQ所有生产者的消息都是往这一个地方存的。

右边是ConsumeQueue。这是一个逻辑队列。和上文中Topic下的messageQueue是一一对应的。消费者是直接和ConsumeQueue打交道。ConsumeQueue记录了消费位点，这个消费位点关联了commitlog的位置。所以即使ConsumeQueue出问题，只要commitlog还在，消息就没丢，可以恢复出来。还可以通过修改消费位点来重放或跳过一些消息。

部署模型

在部署RocketMQ时，会部署两种角色。NameServer和Broker。NameServer主要做路由服务。生产者发送消息时，首先向NameServer拿到Topic的路由信息，即这个Topic在哪些Broker上有。Consumer也是一样，需要知道消费队列的路由情况。当然不是每次收发消息都去NameServer查询一遍，简单的说只有第一次初始化，和以后发送或这首出现问题时需要查询一下。

Broker一般我们会部署主备两个节点。

RocketMq没有选举，broker的角色是在部署时就人工确定好的。如果主挂了，备不会自动切换为主。

对于一个2主2备的集群来说，如果挂了一个主，是没有问题的。只要另一个主上你之前也创建了Topic，那么发送的消息流量会导流到存活的主节点上，业务代码端是无影响的。