7：RocketMq原理 高效能的RocketMQ（Consu
2021-04-13 本文已影响0人
_River_
1：什么是Offset
message queue是无限长的数组，一条消息进来下标就会涨1,下标就是offset，
消息在某个 MessageQueue里的位置，通过offset的值可以定位到这条消息，或者指示Consumer从这条消息开始向后处理
message queue中的maxOffset表示消息的最大offset,
maxOffset并不是最新的那条消息的 offset，而是最新消息的offset+1, minOffset则是现存在的最小offset。
broker的config配置：
deleteWhen = 04 （每天凌晨4点删除日志）
fileReserveTime=48 （默认消息存储48小时）（48小时之前的消费会被物理地从磁盘删除）
message queue 的min offset也就对应增长。
所以比minOffset还要小的那些消息已经不在broker上了，就无法被消费。
类型（父类是0ffsetStore）:
Broker代存储类型：
DefaultMQPushConsumer的CLUSTERING模式，
由Broker端存储和控制Offset的值， 使用 RemoteBrokerOffsetStore
本地文件类型
DefaultMQPushConsumer 的 BROADCASTING 模式，
各Consumer没有互相干扰，使用LoclaFileOffsetStore,把Offset存储在本地
offset作用：
主要是记录消息的偏移量，有多个消费者进行消费
建议采用pushConsumer, RocketMQ自动维护OffsetStore,
不管Offset时存储在是Broker代存储类型还是本地文件类型，最后都是RocketMQ进行管理的 不需要自己管理
如果用另外一种pullConsumer，为了更加灵活的管理消息的消费（可以针对pullConsumer对应的方法进行重写），
除了Offset是存放在本地 还需要自己进行维护OffsetStore
2：什么是CommitLog
消息存储是由ConsumeQueue和CommitLog配合完成
ConsumeQueue:是逻辑队列 （会被持久化）
CommitLog：是真正存储消息文件的，存储的是指向物理存储的地址（会被持久化）
ConsumeQueue 存储的是 消息在CommitLog中的offset。
ConsumeQueue 可以看做是 CommitLog的索引文件。
1：可以通过ConsumeQueue保存的offset（offsetTable.offset json文件中保存的ConsumerQueue的下标）
快速的定位到CommitLog的具体消息的位置。
2：过滤tag是也是通过遍历ConsumeQueue来实现的（先比较hash(tag)符合条件的再到consumer比较tag原文）
而不需要经过CommitLog。
ConsumeQueue：
Topic下的每个message queue都有对应的ConsumeQueue文件，内容也会被持久化到磁盘
默认地址： store/consumequeue/{topicName}/{queueid}/fileName
CommitLog
生成规则：
每个文件的默认1G =1024 * 1024 *1024,
commitlog的文件名fileName，名字长度为20位，左边补零，剩余为起始偏移量；
1：第一个文件名称为00000000000000000000，起始偏移量为0,文件大小为1G=1 073 741 824Byte；
2：当这个文件满了，消息存储的时候会顺序写入文件，当文件满了则写入下一个文件
3：第二个文件名字为00000000001073741824,起始偏移量为1073741824。
判断消息存储在哪个CommitLog上
例如1073742827为物理偏移量，则其对应的相对偏移量 1073742827 - 1073741824 =为1003
并且该偏移量位于第二个CommitLog。
Broker 里面多个Topic（一对多）
一个 Topic里面有多个MesssageQueue（一对多）
每个 MessageQueue 都对应一个 ConsumeQueue （一对一）
ConsumeQueue里面记录的是Off 在CommitLog里面的物理存储地址
3：高性能分析之ZeroCopy零拷贝技术讲解
RocketMQ的高效原因
CommitLog顺序写，存储了MessagBody、message key、tag等信息
ConsumeQueue随机读（索引）+操作系统的PageCache（缓存） +零拷贝技术ZeroCopy（最重要）
ConsumeQueue 与 CommitLog 的关系 ：
通过 存储在ConsumeQueue的offset 快速查找 CommitLog
ConsumeQueue的零拷贝技术ZeroCopy：
零拷贝技术
read(file, tmp_buf, len);
write(socket, tmp_buf, len);
例子：
将一个File读取并发送出去(Linux有两个上下文，内核态，用户态)
File文件的经历了4次copy
kerneI = 内核态 user = 用户态
1：调用read,将文件 从磁盘拷贝 到了内核态
2：CPU控制 内核态的数据拷贝 到了用户态
3：调用write时，用户态下的内容会 拷贝到内核态的socket的buffer中 :
4：最后将内核态socket buffer的数据拷贝到网卡设备中传送
缺点：增加了上下文切换、浪费了2次无效拷贝(即步骤2和3)
最关键是该逻辑需要经过 用户态（Linux系统的 Security Processing 处理）
不能在内核态直接处理数据
ZeroCopy：
请求kernel直接把disk的data传输绐socket，而不是通过应用程序传输。
Zero copy 大大提高了应用程序的性能，减少不必要的内核缓冲区跟用户缓冲区间的拷贝，
从而减少CPU的开销和减少了 kernel和u er模式的上下文切换，达到性能的提升
对应零拷贝技术有mmap及sendfile
-mmap:小文件传输快
RocketMQ选择这种方式，mmap+write方式，小块数据传输，效果会比sendfile更好
sendfile:大文件传输比mmap快
应用：Kafka Netty RocketMq都使用了零拷贝的技术。
