RocketMQ 基本概念

RocketMQ的由来

随着使⽤中队列和虚拟主题的增加，阿⾥巴巴团队使⽤的 ActiveMQ IO 模块达到了瓶颈。为了尽⼒通过节流、断路器或降级来解决这个问题，但效果不佳。所以开始关注当时流⾏的消息传递解决⽅案Kafka 。不幸的是， Kafka ⽆法满⾜要求（在这么多消息队列中间，kafka性能是最靠谱的，但是会出现丢消息的问题），尤其是在低延迟和⾼可靠性⽅⾯。

在这种情况下，决定发明⼀种新的消息传递引擎来处理更⼴泛的⽤例，从传统的发布/ 订阅场景到⼤容量实时零丢失交易系统。⽬前RocketMQ已经开源给 Apache 基⾦会。如今，已有 100 多家公司在其业务中使⽤开源版本的 RocketMQ 。

RocketMQ 由四部分组成：

• 生产者 - Producer
• 消费者 - Consumer
• 协调中心 - NameServer
• 暂存及传输组件 - Broker
• 消息类型 - Topic
• 消息队列 - Message Queue

                                             RocketMQ角色关系图

技术架构

RocketMQ架构上主要分为四部分，如上图所示:

• Producer：消息发布的⻆⾊，⽀持分布式集群⽅式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进⾏消息投递，投递的过程⽀持快速失败并且低延迟。

左边的生产者可以是一个集群，右边是消费者，消费者也可以是一个集群。集群的作用就是提高性能和保证其稳定性。生产者集群里面会有多个生产者，生产者主要功能就是将消息发送给消息队列。

• Consumer：消息消费的⻆⾊，⽀持分布式集群⽅式部署。⽀持以push推，pull拉两种模式对消息进⾏消费。同时也⽀持集群⽅式和⼴播⽅式的消费，它提供实时消息订阅机制，可以满⾜⼤多数⽤户的需求。

消费者主要功能就是从消息队列拉取消息，或者说接收消息。

• NameServer（轻量级注册中心）：NameServer是⼀个⾮常简单的Topic路由注册中⼼，其⻆⾊类似Dubbo中的zookeeper，⽀持Broker的动态注册与发现。

在nameserver集群里面，多台nameserver节点之间是无状态的，他们相互之间不需要知道彼此的状态。nameserver启动了，它不需要知道集群中有几台nameserver。

启动了nameserver1，那么nameserver1就是独立的个体。即使集群当中可能有nameserver2，nameserver3，对于nameserver1来说是不知道其他人的存在。这样的话就能够保证他们的无状态。

注册中心：有数据可以注册上来，那么还有订阅者从注册中心订阅到它所需要的数据。对于nameserver也是一样，什么样的数据可以注册上来呢？真正消息队列的中间件broker，broker可以理解为提供消息服务的角色。消息服务或者说整个rocketmq里面所有的功能，这样一个功能，工具，可以使用broker来描述。

主要包括两个功能：

1. Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供⼼跳检测机制，检查Broker是否还存活。
2. 路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和⽤于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从⽽进⾏消息的投递和消费。NameServer通常也是集群的⽅式部署，各实例间相互不进⾏信息通讯。Broker是向每⼀台NameServer注册⾃⼰的路由信息，所以每⼀个NameServer实例上⾯都保存⼀份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。

这里有很多broker，简单理解就是有很多rocketmq。 除了有好多台mq，还会发现有master和slave。两个broker之间构成了主从。

主从目的可以提升性能，读写可以在broker master，读可以在broke他slave。也就是两个broker都可以提供读的服务，这样性能会更加好。

当有一个master挂了，slave可以顶上，这样就形成了broker的高可用。两个broker都是主从关系，一个broker可以存放一部分数据，另外一个broker可以存放另外一部分数据。当然broker master1和broker master2的数据可以是相同的。

rockermq是重topic的mq，也就是它需要有topic才能整个工作机制可以顺利的运行。topic就是主题的意思。

对于生产者需要将消息发送到某一个topic上，但是实际的消息存储在broker上面，topic是用来区分消息的。

BrokerServer ： Broker 主要负责消息的存储、投递和查询以及服务⾼可⽤保证， 为了实现这些功能，Broker 包含了以下⼏个重要⼦模块。

1. Remoting Module：整个Broker的实体，负责处理来⾃clients端的请求。
2. Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息
3. Store Service：提供⽅便简单的API接⼝处理消息存储到物理硬盘和查询功能。
4. HA Service：⾼可⽤服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
5. Index Service：根据特定的Message key对投递到Broker的消息进⾏索引服务，以提供消息的快速查询。

对于生产者producer来说要将消息发送给某个topic上， 比如消息发送到t1这个topic，t1的topic在broker master1上面，那么消息就会存储在这个topic上面。如果又发消息给t2这个topic，那么t2 topic是放在broker master2上面。很显然这个消息会存储在broker master2上面。

也就是生产者通过topic将消息进行区分，当然两个broker之间也可以保存相同的topic。

生产者是怎么将消息发送到broker上面的呢？它是怎么知道broker的地址呢？在broker集群里面会有很多的broker，这些broker要将自己的信息注册到nameserver上面。

在nameserver集群里面，多台nameserver节点之间是无状态的，他们相互之间不需要知道彼此的状态。nameserver启动了，它不需要知道集群中有几台nameserver。

启动了nameserver1，那么nameserver1就是独立的个体。即使集群当中可能有nameserver2，nameserver3，对于nameserver1来说是不知道其他人的存在。这样的话就能够保证他们的无状态。

broker会去将自己的信息同时注册到nameserver的每一台节点上面。比如broker master1里面存放了topic1这样一个topic。注册到nameserver里面就会有一条映射关系topic1->broker1，或者topic2->broker2，这样的映射关系就会存在于每一台nameserver。

对于producter来说需要去做broker的discover。就是去发现broker，要发到t1上面，这样producer就要去nameserver里面订阅。发送到t1上面到底需要哪个broker呢？nameserver cluster会告诉你。

生产者拿到broker的地址，那么就会将发送到topic1的消息发送到这个broker上面broker master1上面。

消息发过去对于broker集群来说，站在生产者角度来说是同一个broker，只不过在这个地方部署了主从。主负责写，从负责读，主也能实现部分读数据的功能。

消费者要消费某一个topic，它也要去nameserver订阅broker，消费者的topic t1在哪个broker上面。然后连接到该broker上面。