前言
本篇学习了解RocktMq入门核心基本的原理概念以及记录一些基本解析。
消息的存储结构
生产者发送后,在消费者消费前的存储结构图
consume Queue 存在消息在CommitLog中的位置
- 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
- NameServer 轻量级,代码行数1000多行
- RocketMQ追求的是AP,不是CP,需要高可用
- zk是CP,虽然有数据共享,每个节点数据会一致性,但zk集群挂掉了一半以上就不能用
- NameServer是AP,节点间不通信,这样会导致节点间数据信息会发生短暂的不一致,但每个broker都会定时向所有nameserver上报路由信息和心跳;当某个broker下线了,NameServer也会延时30s才知道,而且不会通知客户端(生产和消费者),只能靠客户端自己来拉,RocketMQ 是靠消息重试机制解决这个问题的,所以是最终一致性;但NameServer集群只要有一个节点就可用;
结尾
这个文章主要也是入门级的了解RocketMQ的基本核心原理概念,从消息的基本存储结构,以及刷盘的两种方式河NameServer协调者的作用。