当前位置: 首页>后端>正文

RocketMQ之入门学习核心基本原理(四)

前言

本篇学习了解RocktMq入门核心基本的原理概念以及记录一些基本解析。

消息的存储结构

生产者发送后,在消费者消费前的存储结构图
consume Queue 存在消息在CommitLog中的位置


RocketMQ之入门学习核心基本原理(四),第1张
  • 1、 消费端采用零拷贝
  • 2、Commit log存储消息实体(真实数据)。顺序写,随机读。
  • 3、consume Queue 记录在CommitLog位置,类似于索引文件,一对多的关系
  • 4、每一个topic,message queue 都对应一个Consume Queue,具体的值海是读取commit log消息本身。
    -5、Index 消息属性检索消息,引入ConsumeQueue文件解决了基于topic查找消息的问题
    -6、CommitLog里存储了Consume Queues、Message Queue、Tag等所有信息,即使ConsumeQueue丢失,也可以通过commitLog完全恢复出来

同步刷盘与异步刷盘

RocketMQ消息存储:内存 + 磁盘存储,两种刷盘方式
存储与读写是基于JDK NIO的内存映射机制(MappedByteBuffer),消息存储时首先将消息追加到文件内存映射(commit操作),再根据配置的刷盘策略在不同时间进行刷写到磁盘(flush操作)。

同步刷盘

同步刷盘即持久化成功后才向客户端返回成功。以牺牲写入性能为代价。

异步刷盘

异步刷盘是指 Broker 将消息存储到页缓存后就立即返回成功,然后开启一个异步线程定时将内存中的数据写入磁盘,默认间隔时间 500ms。

高可用机制

  • 集群有两个角色,Master-Salve
  • 根据BorkerId区分主从节点
  • Master读写,Slave只写
  • 当Master繁忙或者不可用时,可以自动切换到Slave读取消息

NameServer协调者

对于一个消息队列集群来说是整个集群的状态服务器,系统由很多台机器组成,每个机器的角色、IP 地址都不相同,而且这些信息是变动的。这种情况下, 如果一个新的Producer 或Consumer 加入,怎么配置连接信息呢?NameServer 的存在主要是为了解决这类问题,由NameServer 维护这些配置信息、状态信息,其他角色都通过NameServer 来协同执行

  • NameServer部署、相互独立
    Nameserver是一个独立的元数据管理组件,它需要独立运行,并且与Broker和Consumer分开部署。通常情况下,建议在集群中至少部署两个Nameserver节点,以确保高可用性。
  • NameServer 维护的主要信息:
  • topic-》List<queueData> 某个Broker的队列
  • 为什么不用Zookpper
  1. NameServer 轻量级,代码行数1000多行
  2. RocketMQ追求的是AP,不是CP,需要高可用
  3. zk是CP,虽然有数据共享,每个节点数据会一致性,但zk集群挂掉了一半以上就不能用
  4. NameServer是AP,节点间不通信,这样会导致节点间数据信息会发生短暂的不一致,但每个broker都会定时向所有nameserver上报路由信息和心跳;当某个broker下线了,NameServer也会延时30s才知道,而且不会通知客户端(生产和消费者),只能靠客户端自己来拉,RocketMQ 是靠消息重试机制解决这个问题的,所以是最终一致性;但NameServer集群只要有一个节点就可用;

结尾

这个文章主要也是入门级的了解RocketMQ的基本核心原理概念,从消息的基本存储结构,以及刷盘的两种方式河NameServer协调者的作用。


https://www.xamrdz.com/backend/3yw1924911.html

相关文章: