RocketMQ 核心源码

RocketMQ 由NameServer 集群、Producer 集群、consumer 集群、broker 集群组成。

一、消费生产大致原理  

1. Broker 在启动的时候向所有NameServer 注册，并保持长连接，每30s 发送一次心跳。
2. Producer 在发送消息的时候从NameServer 获取Broker 服务器地址，根据负载均衡选择一个服务器来发送消息
3. Consumer 消费消息同样是从NamerServer 获取Broker 地址，然后主动拉取消息。
Topic 区分消息的种类。
一个发送者可以发送消息给多个topic；一个消费者可以订阅多个topic。
MessageQueue：相当于topic 的分区。用于发送和接收消息。

二、 简述RocketMQ 的持久化机制

三个重要的存储文件：

1. commitLog 消息文件：

被所有的queue 共享，大小为1G，写满后重新生成，顺序写。

2. consumeQueue 消费队列文件：

逻辑queue，消息先到达conmmitLog，然后异步转发到consumerQueue，包含queue 在commitLog 中的偏移量offset、消息实体大小、和消息tag 的hash。写满后重新生成，顺序写。
大小为600w 字节。

3. indexFile 索引文件：

通过key 或者时间区间来查找commitLog 中的消息，文件名以创建的时间戳命名。
固定大小为400M。
所有的队列共用一个日志文件，避免了像kafka 的分区数过多、日志文件过多导致磁盘IO 读写压力较大的问题。

三、刷盘机制：

1. 同步刷盘

消息持久化到磁盘会给生产者返回ack，可以保证消息可靠，但是会影响性能。

2. 异步刷盘

消息写入page cache 就返回ack，提高性能和吞吐量，但会有消息丢失的问题。

RocketMQ 文件保存72 小时，在凌晨4 点将过期文件删除。
RocketMQ 中queue 文件的优缺点：
优点： 只存储少量的数据，更加轻量化。
缺点：写入是顺序的，读取是随机的。先读consumeQueue，再度commitLog，降低读取效率。