美文网首页
7:RocketMq原理 高效能的RocketMQ(Consu

7:RocketMq原理 高效能的RocketMQ(Consu

作者: _River_ | 来源:发表于2021-04-13 15:25 被阅读0次
    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都使用了零拷贝的技术。
    

    相关文章

      网友评论

          本文标题:7:RocketMq原理 高效能的RocketMQ(Consu

          本文链接:https://www.haomeiwen.com/subject/wohclltx.html