rocketmq学习及其内部实现原理

什么是rocketmq

mq: message queue,中文翻译为消息队列，是一种为两个或多个不同分布式系统间提供的异步的消息传递的中间件，常用于大数据量下的应用解耦、流量削峰、数据分发等场景。而RocketMQ是阿里巴巴2016年开源的一款MQ中间件，使用Java语言开发，在阿里内部，RocketMQ承接了例如“双11”等高并发场景的消息流转，能够处理万亿级别的消息。

rocketmq的组织构架

在rocketmq中总共存在着4个角色，分别是生产消息的生产者provider、消费消息的消费者consumer、mq的主要工作服务器集群Broker、负责Broker服务发现的nameServer，消息的主题Topic和每个topic的消息分区队列Message Queue。

• provider：负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。
• consumer：负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。
• broker server：消息中转角色，负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。
• name server：名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表，其功能类似于VipServer。
• Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者可以订阅一个或者多个Topic消息
• Message Queue：相当于是Topic的分区；用于并行发送和接收消息，一个topic会分区存储在多个queue中。

​

为了保证整个系统的高可用性，mq的各个组成成分都是采用集群方式搭建的，对于生产者和消费者而言，其本身就是多台服务器共同使用mq，因此它们本身就是集群的，没什么特殊，主要说说nameserver和broker的集群方式。

• nameserver集群：NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。
• broker server集群：broker server的集群是相对复杂的，首先broker服务器分为Master与Slave两种服务器，它们和起来称为一个broker组，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，在集群配置时Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave，在系统部署是一般集群了多个主从服务器组合，每个组合中又包含了一个或多个Slave节点。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。

系统启动的工作流程如下：

• 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连接，相当于一个路由控制中心。
• Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
• 在broker收发消息前，首先要在管理中心中创建Topic，并指定该Topic要存储在哪些broker组中。
• Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列(一个队列其实就对应了一台broker机器)，然后与队列所在的Master Broker建立长连接从而向Broker发消息，发送消息后Master broker会将消息同步到指定的从broker中。
• Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。

​

如何保证消息发送的事务性

rocketmq的事务主要体现在保证provider提交的事务消息一定在broker服务器中完成了刷盘了持久化存储，rocketmq解决该问题的方法借鉴了分布式事务中的两阶段提交策略，同时还增加了一个补偿回查的机制来实现进一步保证一致性，具体实现过程如下：

• 1、首先provider提交一条half消息，half消息类似于数据库中的日志文件。
• 2、服务端将half消息写入本地，并且回复一个应答信号给provier，如果此时broker未能成功写入，则返回失败。注意，此时数据已经实际传到了broker服务器，但是该消息对用户不可见，不影响实际过程。
• 3、provider收到应答后开始执行本地事务，例如修改本地标志为已成功发送。
• 4、然后向broker服务器发送提交信号，broker服务器收到后将消息写入本地逻辑