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 时立刻通知刷盘线程刷盘,刷盘成功后唤醒线程,返回消息写成功。