RocketMQ介绍及其工作原理

RocketMQ是一个开源的分布式消息中间件。

集群架构与角色

rocket1.png

Producer先去NameServer请求，NameServer分配一个Broker给Producer，Producer再去访问对应的Broker。

Broker需要自动上报状态信息到NameServer。

Consumer消费消息时，也要先询问NameServer，获得一个Broker地址，再消费Broker的消息。

• NameServer
  是无状态的，Broker会向每个NameServer上报自己信息。

• Broker Server
  Broker分为maser与slave，一个master可以对应多个slave，一个slave只能对应一个master。
  master与slave有相同的brokername，BrokderID=0表示为master，非0表示slave。Broker与NameServer所有节点建立长连接，定时注册Topic信息到所有NameServer.

• Producer
  与NameServer中一个节点建立长连接，定期从NameServer获取Topic信息，并向提供Topic服务的Master建立长连接，定时发送心跳。Producer无状态

• Consumer
  与NameServer中一个节点建立长连接，定期从NameServer获取Topic信息，并向提供Topic服务的Master、Slave建立长连接，定时发送心跳。Consumer可以从Master订阅消息，也可以从Slave订阅消息，规则由Broker决定

• Topic
  区分消息的种类，一个发送者可以发送消息给一个或者多个Topic，一个消息的接受者可以订阅一个或者多个Topic消息

• Message Queue:
  相当于Topic的分区，用于并行发送和接收消息。

集群工作流程

1. 启动NameServer后，NameServer会监听端口，等待Broker，Producer，Consumer连上来。
2. Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息以及存储的所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
3. 收到消息前，会先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
4. Producer发送消息，启动时先跟NameServer集群中的其中一个建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列。然后与队列所在Broker建立长连接，从而向Broker发送消息。
5. Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接，开始消费消息。

零拷贝技术

Linux操作系统分为用户态和内核态，文件操作，网络操作需要涉及这两种形态的切换，免不了进行数据复制。
一台服务器把本机磁盘文件的内容发送到客户端，一般分为2个步骤：
（1）读取本地文件内容
（2）将读取的内容通过网络发送出去

这两个看似简单的操作，实际进行了4次数据复制：
（1）从磁盘复制数据到内核态内存
（2）从内核态内存复制到用户态内存
（3）然后从用户态内存复制到网络驱动的内核态内存
（4）最后是从网络驱动的内核态内存复制到网卡中进行传输

零拷贝技术就是将数据直接从内核态复制到网络驱动内核态，可以省去向用户态的内存复制，提高效率。这种机制在Java中是通过DirectByteBuffer实现的。RocketMQ充分利用了上述特性，也就是所谓的“零拷贝”，提高消息存盘和网络发送的速度

但是这个API有一个限制，一次只能映射1.5 - 2G的文件。这也是为何RocketMQ默认设置单个CommitLog日志数据文件为1G的原因。

存储结构

rocket2.png

RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成的，消息真正的物理存储文件是CommitLog，ConsumeQueue是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每个Topic下的MessageQueue都有一个对应的ConsumeQueue文件。

• CommitLog: 存储消息的元数据
• ConsumeQueue: 存储消息在CommitLog的索引
• IndexFile: 为消息查询提供了一种通过Key或者时间区域来查询消息的方法。这种通过IndexFile来查找消息的方法不影响发送和消息消费的主流程。

CommitLog的清理：

1. 消息文件过期（默认72小时），且到达清理时间点（默认凌晨4点），删除过期文件
2. 消息文件过期（默认72小时），且磁盘空间达到水平线（默认75%），删除过期文件
3. 磁盘已经达到必须释放上限（85%）的时候，则开始批量清理文件，直到空间充足

刷盘机制

RocketMQ的消息是存储在磁盘上的，这样既能保证断电后恢复，又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入MQ的时候，有两种写磁盘方式：

rocket3.png

（1）同步刷盘
在返回写成功状态时，消息已经被写入磁盘。
（2）异步刷盘
在返回写成功状态时，消息可能只是被写入了内存中。写操作的返回块，吞吐量大；当内存里的数据积累到一定程度时，统一触发写磁盘动作，快速写入。

配置：
Broker配置文件里的flushDiskType参数可进行设置

主从复制

如果一个Broker组有Master和Slave，消息需要从Master复制到Slave上，有同步和异步两种复制方式：
（1）同步复制
等Master和Slave均写成功后才反馈客户端写成功状态。
在同步复制方式下，如果Master出故障，Slave上有全部的备份数据，容易恢复。但是同步复制会增加数据写入延迟，降低吞吐量。
（2）异步复制
只要Master写成功就返回写成功状态。
在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但可能存在数据丢失的风险。

配置：
Broker配置文件里brokerRole参数可进行配置。

顺序消费

一个Topic下可以有多个Queue，消费端可以监听多个queue进行并发消费，一个Queue中的消息是有顺序的，要实现顺序消费，只需要指定对应的一个queue就能实现顺序消费。