Rocketmq 一文带你搞懂rocketmq基础

news2024/11/25 2:21:50

1.集群架构

从上图可以看出来一共有4个部分，分别为Producer,Consumer,NameServer,Broker

1.1 NameServer集群

虽然说NameServer是一个集群，但是每一个NameServer是独立的，不会相互同步数据，因为每个节点都会保存完整的数据，所以单个节点挂掉不会影响集群。

1.2Broker

Broker 采用主从集群，实现多副本存储和高可用。每个 Broker 节点都要跟所有的 Name Server 节点建立长连接，定义注册 Topic 路由信息和发送心跳。跟所有 Name Server 建立连接，就不会因为单个 Name Server 挂了影响 Broker 使用。Broker 主从模式中， Slave 节点主动从 Master 节点拉取消息。

1.3Producer

生产者，Producer 跟 Name Server 的任意一个节点建立长连接，定期从 Name Server 拉取 Topic 路由信息。Producer 是否采用集群，取决于它所在的业务系统。

1.4 consumer

Consumer 跟 Name Server 的任意一个节点建立长连接，定期从 Name Server 拉取 Topic 路由信息。Consumer 是否采用集群，取决于它所在的业务系统。

Producer 和 Consumer 只跟任意一个 Name Server 节点建立连接，因为 Broker 会向所有 Name Server 注册 Topic 信息，所以每个 Name Server 保存的数据其实是一致的。

2.MessageQueue

producer发送的消息会在Broke中的MessageQueue中保存，保存的是消息的偏移量

有了 MessageQueue ，Topic 的消息就可以在 Broker 中实现分布式存储，如上图，Broker 集群中有 3 个 Broker，保存两个 Topic 的消息。每个 Broker 为 Topic 创建 4 个MessageQueue。

有了 MessageQueue，Producer 可以并发地向 Broker 中发送消息，Consumer 也可以并发地消费消息。

3.Consumer

图中，RocketMQ 集群中有两个 Broker，每个 Broker 上有 4 个 MessageQueue，Topic1 的消息并发写入了这 8 个 MessageQueue。

RocketMQ 通过 Consumer Group1 这个消费者组进行消息拉取。

一个消费者可以消费多个 MessageQueue，但是同一个 MessageQueue 只能被同一个消费者组的一个消费者消费。比如 MessageQueue0 只能被 Consumer Group1 中的 Consumer1 消费，不能被其他消费者消费。

4.Broker高可用集群

Broker 通过主从集群来实现消息高可用。跟 Kafka 不同的是，RocketMQ 并没有 Master 节点选举功能，而是采用多 Master 多Slave 的集群架构。Producer 写入消息时写入 Master 节点，Slave 节点主动从 Master 节点拉取数据来保持跟 Master 节点的数据一致。

Consumer 消费消息时，既可以从 Master 节点拉取数据，也可以从 Slave 节点拉取数据。到底是从 Master 拉取还是从 Slave 拉取取决于 Master 节点的负载和 Slave 的同步情况。如果 Master 负载很高，Master 会通知 Consumer 从 Slave 拉取消息，而如果 Slave 同步消息进度延后，则 Master 会通知 Consumer 从 Master 拉取数据。总之，从 Master 拉取还是从 Slave 拉取由 Master 来决定。

如果 Master 节点发生故障，RocketMQ 会使用基于 raft 协议的 DLedger 算法来进行主从切换。

Broker 每隔 30s 向 Name Server 发送心跳，Name Server 如果 120s 没有收到心跳，就会判断 Broker 宕机了。

5.消息存储

存储文件一共有三个：CommitLog,ConsumeQueue,Index

5.1CommitLog

Rocketmq的消息保存在CommitLog里面，CommitLog每个文件大小1G，文件名并不叫CommitLog,而是通过消息的偏移量来命名，比如第一个文件文件名是 0000000000000000000，第二个文件文件名是 00000000001073741824，依次类推就可以得到所有文件的文件名。

有了上面的命名规则，给定一个消息的偏移量，就可以根据二分查找快速找到消息所在的文件，并且用消息偏移量减去文件名就可以得到消息在文件中的偏移量。

RocketMQ 写 CommitLog 时采用顺序写，大大提高了写入性能。

5.2ConsumeQueue

如果从CommitLog里面检索一条消息效率会很低，这时候ConsumeQueue就会充当索引文件，会让检索效率大大提高

其实ConsumeQueue和MessageQueue是一一对应的关系，MessageQueue只是一个概念模型

commitLogffset ：记录消息在CommitLog中的偏移量

size:记录消息大小

tag hashCode: 这个很重要，假如一个Consumer订阅了TopicA,Tag1,Tag2,那这个Consumer的订阅关系如下：

可以看到，这个订阅关系是一个 hash 类型的结构，key 是 Topic 名称，value 是一个 SubscriptionData 类型的对象，这个对象封装了 tag。

拉取消息时，首先从 Name Server 获取订阅关系，得到当前 Consumer 所有订阅 tag 的 hashcode 集合 codeSet，然后从 ConsumerQueue 获取一条记录，判断最后 8 个字节 tag hashcode 是否在 codeSet 中，以决定是否将该消息发送给Consumer。

5.3index文件

因为Rocketmq支持消息的属性查找消息，所以出现了index文件 index文件由三个部分组成

文件头，indexhead 500W个hash槽，和2000W个Index条目组成

5.3.1 indexhead

由6部分组成

前两个元素代表是这个index文件中第一条消息和最后一条消息的罗盘时间

第三个第四个元素是表示当前index文件中第一条消息和最后一条消息在Commitlog中的物理偏移量，

第五个元素代表还有多少hash槽数量

第六个元素表示当前index文件中索引条数的数量

查找的时候除了传入 key 还需要传入第一条消息和最后一条消息的落盘时间，这是因为 Index 文件名是时间戳命名的，传入落盘时间可以更加精确地定位 Index 文件。

5.3.2hash槽

熟悉 Java 中 HashMap 的同学应该都比较熟悉 Hash 槽这个概念了，其实就是 Hash 结构的底层数组。Index 文件中的 Hash 槽有 500 万个数组元素，每个元素是 4 个字节 int 类型元素，保存当前槽下最新的那个 index 条目的序号。

hash槽解决hash冲突的方法是链表法

5.3.3Index条目

每个 Index 条目中，key 的 hashcode 占 4 个字节，phyoffset 表示消息在 CommitLog 中的物理偏移量占 8 个字节，timediff 表示消息的落盘时间与 header 里的 beginTimestamp 的差值占 4 个字节，pre index no 占 4 个字节。

re index no 保存的是当前的 Hash 槽中前一个 index 条目的序号，一般在 key 发生 Hash 冲突时才会有值，否则这个值就是 0，表示当前元素是 Hash 槽中第一个元素。

Index 条目中保存 timediff，是为了防止 key 重复。查找 key 时，在 key 相同的情况下，如果传入的时间范围跟 timediff 不满足，则会查找 pre index no 这个条目。