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都使用了零拷贝的技术。
网友评论