[rocketmq] 浅谈结构

rocketmq 结构

NameServer ：几乎是无状态节点，可横向扩展，节点之间无消息同步，主要负责对源数据的管理，包括对于Topic和路由信息的管理。

每个 Broker 在启动的时候会到 NameServer 注册，Producer 在发送消息前会根据 Topic 到 NameServer 获取到 Broker 的路由信息，Consumer 也会定时获取 Topic 的路由信息。

Broker：，定时扫描 producer 链接，主要负责消息的存储、投递和查询以及服务高可用保证 ，单个 broker 与所有 nameserver 有长链接，定时将topic信息注册到nameServer

Producer：负责产生消息，通过多种负载均衡模式发送到Broker集群。从 nameserver 获取 topic 信息。启动时会在 nameserver 注册，发消息前会从 nameserver 获取信息。

Comsumer ：定时从 nameserver 获取 borker 信息，从broker获取 topic 队列消息，支持push和pull两种获取消息的模式，支持集群和广播消费，提供实时的消息订阅机制。
pull主动从消息服务器拉取消息，只要批量拉取到消息用户就会启动消费过程
push 封装消息的拉取、消费进度等，将消息到达时执行的回调接口留给用户应用程序实现，首先要注册消费监听器，当监听器触发后才开始消费消息。

心跳机制

broker会每隔30秒向NameServer发送一个的心跳 ，NameServer收到一个心跳会更新对应broker的最近一次心跳事件，然后NamServer会每隔十秒运行一个任务，去检查一下各个broker的最近一次心跳的时间，如果超过120s没有收到相应broker的心跳，则判定对应的broker已经挂掉。

集群

nameserver 是无状态的，所以可横向扩展，producer 和 consumer 都是由业务端控制，所以是业务集群，rocketmq 中 broker 为保障数据不丢失，此集群为主从模式

消息存储

消息存储是由 message queue 和 commitlog 一起完成的

commitlog 存储消息，是物理存储，顺序写，随机读。
messageQueue 是逻辑存储， 文件夹的组织方式如下：topic/queue/file。存储指向 commitlog 的具体位置，会持久化，保存了指定 Topic 下的队列消息在 CommitLog 中的起始物理偏移量 offset ，消息大小 size 和消息 Tag 的 HashCode 值

一个 topic 可能有多个 message queue， offset 指一个消息在某一个 message queue 下的具体位置，通过 offset 可以定位某一个消息

同步刷盘/异步刷盘

异步刷盘：返回写成功状态时，消息可能只是写入 pagecache 中，等消息积累到一定程度会刷新到磁盘中
同步刷盘：返回写成功状态时，消息已经保存到磁盘中，消息写入 pagecache 时立刻通知刷盘线程刷盘，刷盘成功后唤醒线程，返回消息写成功。