前言
本篇学习了解RocktMq入门核心基本的原理概念以及记录一些基本解析。
消息的存储结构
生产者发送后，在消费者消费前的存储结构图
consume Queue 存在消息在CommitLog中的位置
image.png
- 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协调者的作用。
