RocketMq存储之___消息写入内存

最新推荐文章于 2024-11-25 17:27:16 发布
原创 最新推荐文章于 2024-11-25 17:27:16 发布 · 614 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java-rocketmq #rocketmq #java

本文详细解析RocketMQ消息存储的整个过程，包括消息存入缓存的入口接口、存储前的校验步骤、组装消息体信息的具体实现，以及消息最终存储到CommitLog文件中的详细流程。

文章目录

一、消息存入缓存 入口接口： putMessage()

  • location: org.apache.rocketmq.store.MessageStore#putMessage :
/**
     * Store a message into store.
     *
     * @param msg Message instance to store
     * @return result of store operation.
     */
    PutMessageResult putMessage(final MessageExtBrokerInner msg);

二、实现类：DefaultMessageStore#putMessage

  • location: org.apache.rocketmq.store.DefaultMessageStore#putMessage：
public PutMessageResult putMessage(MessageExtBrokerInner msg) {
    // 1. 校验 broker
		PutMessageStatus checkStoreStatus = this.checkStoreStatus();
		if (checkStoreStatus != PutMessageStatus.PUT_OK) {
		    return new PutMessageResult(checkStoreStatus, null);
		}
		//2. 校验topic 
		PutMessageStatus msgCheckStatus = this.checkMessage(msg);
		if (msgCheckStatus == PutMessageStatus.MESSAGE_ILLEGAL) {
		    return new PutMessageResult(msgCheckStatus, null);
		}
		
		long beginTime = this.getSystemClock().now();
    //3. 存储
		PutMessageResult result = this.commitLog.putMessage(msg);
		long elapsedTime = this.getSystemClock().now() - beginTime;
		if (elapsedTime > 500) {
		    log.warn("not in lock elapsed time(ms)={}, bodyLength={}", elapsedTime, msg.getBody().length);
		}
   // 4. 后续处理
			// 记录写commitlog时间，大于最大时间则设置为这个最新的最大时间 putMessageEntireTimeMax
			this.storeStatsService.setPutMessageEntireTimeMax(elapsedTime);
			
			if (null == result || !result.isOk()) {
			    // 记录写commitlog 失败次数
			    this.storeStatsService.getPutMessageFailedTimes().incrementAndGet();
			}
		
		return result;
}

三、存储前校验

1. 校验broker 的方法checkStoreStatus(）：

private PutMessageStatus checkStoreStatus() {
        //1. 如果当前broker 停止工作，返回
        if (this.shutdown) {
            log.warn("message store has shutdown, so putMessage is forbidden");
            return PutMessageStatus.SERVICE_NOT_AVAILABLE;
        }
       // 2. 如果当前broker 是 Slave 角色
        if (BrokerRole.SLAVE == this.messageStoreConfig.getBrokerRole()) {
            long value = this.printTimes.getAndIncrement();
            if ((value % 50000) == 0) {
                log.warn("broke role is slave, so putMessage is forbidden");
            }
            return PutMessageStatus.SERVICE_NOT_AVAILABLE;
        }
       //3. 如果当前broker 不提供写的能力，返回
        if (!this.runningFlags.isWriteable()) {
            long value = this.printTimes.getAndIncrement();
            if ((value % 50000) == 0) {
                log.warn("the message store is not writable. It may be caused by one of the following reasons: " +
                    "the broker's disk is full, write to logic queue error, write to index file error, etc");
            }
            return PutMessageStatus.SERVICE_NOT_AVAILABLE;
        } else {
            this.printTimes.set(0);
        }
      // 计算CommitLog锁持有时间，是否超过了默认的设置1s 并且小于 10000000
        if (this.isOSPageCacheBusy()) {
            return PutMessageStatus.OS_PAGECACHE_BUSY;
        }
        return PutMessageStatus.PUT_OK;
}

isOSPageCacheBusy() :

计算CommitLog锁持有时间 = 当前时间 - 获取锁开始时间，page cache timeout默认配置的时间是1000ms，也即1s，所以broker在处理上一个消息写入的时候占有锁的时间超过1s的时候就会被认为page cache busy。

public boolean isOSPageCacheBusy() {
    long begin = this.getCommitLog().getBeginTimeInLock();
    long diff = this.systemClock.now() - begin;
    return diff < 10000000
        && diff > this.messageStoreConfig.getOsPageCacheBusyTimeOutMills();
}

2. 校验 topic 的长度和属性的长度：

private PutMessageStatus checkMessage(MessageExtBrokerInner msg) {
      // topic 长度是否大于 127
      if (msg.getTopic().length() > Byte.MAX_VALUE) {
          log.warn("putMessage message topic length too long " + msg.getTopic().length());
          return PutMessageStatus.MESSAGE_ILLEGAL;
      }
      // 消息属性的长度 是否大于  32767
      if (msg.getPropertiesString() != null && msg.getPropertiesString().length() > Short.MAX_VALUE) {
          log.warn("putMessage message properties length too long " + msg.getPropertiesString().length());
          return PutMessageStatus.MESSAGE_ILLEGAL;
      }
      return PutMessageStatus.PUT_OK;
}

四、存储前-组装消息体信息 和 存储结果处理：

commitLog.putMessage()：

  • location: org.apache.rocketmq.store.CommitLog#putMessage
public PutMessageResult putMessage(final MessageExtBrokerInner msg) {
    // Set the storage time
    msg.setStoreTimestamp(System.currentTimeMillis());
    // Set the message body BODY CRC (consider the most appropriate setting
    // on the client)
    msg.setBodyCRC(UtilAll.crc32(msg.getBody()));
    // Back to Results
    AppendMessageResult result = null;

    StoreStatsService storeStatsService = this.defaultMessageStore.getStoreStatsService();

    String topic = msg.getTopic();
    int queueId = msg.getQueueId();

    final int tranType = MessageSysFlag.getTransactionValue(msg.getSysFlag());
    //1. 非事务消息 或 已commit事务消息
    if (tranType == MessageSysFlag.TRANSACTION_NOT_TYPE
        || tranType == MessageSysFlag.TRANSACTION_COMMIT_TYPE) {
        // Delay Delivery
        if (msg.getDelayTimeLevel() > 0) {
            if (msg.getDelayTimeLevel() > this.defaultMessageStore.getScheduleMessageService().getMaxDelayLevel()) {
                msg.setDelayTimeLevel(this.defaultMessageStore.getScheduleMessageService().getMaxDelayLevel());
            }

            topic = TopicValidator.RMQ_SYS_SCHEDULE_TOPIC;
            queueId = ScheduleMessageService.delayLevel2QueueId(msg.getDelayTimeLevel());

            // Backup real topic, queueId
            MessageAccessor.putProperty(msg, MessageConst.PROPERTY_REAL_TOPIC, msg.getTopic());
            MessageAccessor.putProperty(msg, MessageConst.PROPERTY_REAL_QUEUE_ID, String.valueOf(msg.getQueueId()));
            msg.setPropertiesString(MessageDecoder.messageProperties2String(msg.getProperties()));

            msg.setTopic(topic);
            msg.setQueueId(queueId);
        }
    }

    InetSocketAddress bornSocketAddress = (InetSocketAddress) msg.getBornHost();
    if (bornSocketAddress.getAddress() instanceof Inet6Address) {
        msg.setBornHostV6Flag();
    }

    InetSocketAddress storeSocketAddress = (InetSocketAddress) msg.getStoreHost();
    if (storeSocketAddress.getAddress() instanceof Inet6Address) {
        msg.setStoreHostAddressV6Flag();
    }

    long elapsedTimeInLock = 0;
  
    MappedFile unlockMappedFile = null;
    // 2. 获取可以写入的commitLog 文件
    MappedFile mappedFile = this.mappedFileQueue.getLastMappedFile();
    // 3. 获取写入的锁
    putMessageLock.lock(); //spin or ReentrantLock ,depending on store config
    try {
        long beginLockTimestamp = this.defaultMessageStore.getSystemClock().now();
        this.beginTimeInLock = beginLockTimestamp;

        // Here settings are stored timestamp, in order to ensure an orderly
        // global
        // 4. 设置存储时间，为了保证全局有序
        msg.setStoreTimestamp(beginLockTimestamp);
        // 5. 校验获取的mappedFile 是否有值或者已经满了，如果是，创建新的
        if (null == mappedFile || mappedFile.isFull()) {
            mappedFile = this.mappedFileQueue.getLastMappedFile(0); // Mark: NewFile may be cause noise
        }
        if (null == mappedFile) {
            log.error("create mapped file1 error, topic: " + msg.getTopic() + " clientAddr: " + msg.getBornHostString());
            beginTimeInLock = 0;
            return new PutMessageResult(PutMessageStatus.CREATE_MAPEDFILE_FAILED, null);
        }
        // 6. 组装消息完成，将消息追加到 获取到的或者创建的commitLog 文件中
        result = mappedFile.appendMessage(msg, this.appendMessageCallback);
        switch (result.getStatus()) {
            case PUT_OK:
                break;
            case END_OF_FILE:
                unlockMappedFile = mappedFile;
                // Create a new file, re-write the message
                mappedFile = this.mappedFileQueue.getLastMappedFile(0);
                if (null == mappedFile) {
                    // XXX: warn and notify me
                    log.error("create mapped file2 error, topic: " + msg.getTopic() + " clientAddr: " + msg.getBornHostString());
                    beginTimeInLock = 0;
                    return new PutMessageResult(PutMessageStatus.CREATE_MAPEDFILE_FAILED, result);
                }
                result = mappedFile.appendMessage(msg, this.appendMessageCallback);
                break;
            case MESSAGE_SIZE_EXCEEDED:
            case PROPERTIES_SIZE_EXCEEDED:
                beginTimeInLock = 0;
                return new PutMessageResult(PutMessageStatus.MESSAGE_ILLEGAL, result);
            case UNKNOWN_ERROR:
                beginTimeInLock = 0;
                return new PutMessageResult(PutMessageStatus.UNKNOWN_ERROR, result);
            default:
                beginTimeInLock = 0;
                return new PutMessageResult(PutMessageStatus.UNKNOWN_ERROR, result);
        }

        elapsedTimeInLock = this.defaultMessageStore.getSystemClock().now() - beginLockTimestamp;
        beginTimeInLock = 0;
    } finally {
        putMessageLock.unlock();
    }

    if (elapsedTimeInLock > 500) {
        log.warn("[NOTIFYME]putMessage in lock cost time(ms)={}, bodyLength={} AppendMessageResult={}", elapsedTimeInLock, msg.getBody().length, result);
    }

    if (null != unlockMappedFile && this.defaultMessageStore.getMessageStoreConfig().isWarmMapedFileEnable()) {
        this.defaultMessageStore.unlockMappedFile(unlockMappedFile);
    }

    PutMessageResult putMessageResult = new PutMessageResult(PutMessageStatus.PUT_OK, result);

    // Statistics
    storeStatsService.getSinglePutMessageTopicTimesTotal(msg.getTopic()).incrementAndGet();
    storeStatsService.getSinglePutMessageTopicSizeTotal(topic).addAndGet(result.getWroteBytes());

    handleDiskFlush(result, putMessageResult, msg);
    handleHA(result, putMessageResult, msg);

    return putMessageResult;
}

核心流程：

  1. 判断消息的类型，如果是 非事务消息 或 已commit事务消息，判断消息是否设置延迟，如果设置了延迟，将消息的topic 设置为延时消息的topic SCHEDULE_TOPIC_XXXX, QueueId 设置为延时消息的 queueId(一个延迟级别对应一个Queue,根据消息的延迟等级获取对应的延迟队列)。

    同时，把消息的原始topic 和 queue保存在消息的property中。

  2. 获取可以写入的commitLog 文件；

  3. 获取putMessageLock 锁，因为写入CommitLog 文件是串行的。

    1. spin or ReentrantLock ,depending on store config； 获取哪种锁取决于配置文件。

  4. 设置存储时间，为了保证全局有序；

  5. 校验获取的mappedFile(commitLog文件) 是否没值或者已经满了；如果是，根据偏移量 0创建一个新的commitLog 文件，文件为 00000000000000000000 ；如果创建失败，抛出异常。

  6. 组装消息完成，发送 将消息追加到 获取到的或者创建的commitLog 文件中的请求，等待结果；

  7. 如果 6 请求：

    1. 成功：
      1. 释放锁；
      2. 保存对应topic 的添加时间和写入长度；
      3. 刷盘；
      4. HA;
    2. END_OF_FILE （满了，当前commitLog 不够空间了）
      1. 创建一个新的commitLog 去写；继续执行 第 6步；
    3. MESSAGE_SIZE_EXCEEDED，PROPERTIES_SIZE_EXCEEDED，UNKNOWN_ERROR，其他
      1. 直接返回异常。
重要方法介绍： getLastMappedFile()

获取当前可以写入的 Commitlog 件。MappedFile 对应的就是commitLog 文件夹中一个一个文件。

public MappedFile getLastMappedFile() {
    MappedFile mappedFileLast = null;

    while (!this.mappedFiles.isEmpty()) {
        try {
            mappedFileLast = this.mappedFiles.get(this.mappedFiles.size() - 1);
            break;
        } catch (IndexOutOfBoundsException e) {
            //continue;
        } catch (Exception e) {
            log.error("getLastMappedFile has exception.", e);
            break;
        }
    }

    return mappedFileLast;
}

五、信息存储到CommitLog 文件的链路

5.1 前置操作

接口定义：mappedFile.appendMessage(msg,this.appendMessageCallback)

  • location: org.apache.rocketmq.store.MappedFile#appendMessages
public AppendMessageResult appendMessages(final MessageExtBatch messageExtBatch, final AppendMessageCallback cb) {
     return appendMessagesInner(messageExtBatch, cb);
}

实现类：appendMessagesInner(final MessageExt messageExt, final AppendMessageCallback cb) org.apache.rocketmq.store.MappedFile#appendMessagesInner

public AppendMessageResult appendMessagesInner(final MessageExt messageExt, final AppendMessageCallback cb) {
    assert messageExt != null;
    assert cb != null;
    // 1. 获取 MappedFile 当前写指针
    int currentPos = this.wrotePosition.get();
    // 2. 判断 ，如果指针表示的size 小于文件大小
    if (currentPos < this.fileSize) {
        // 3. 创建共享内存区
        //  如果 ByteBuffer 不是null,调用slice 方法创建一个 MappedFile 的共享内存区 否则调用 mappedByteBuffer 的slice 方法；
        
        ByteBuffer byteBuffer = writeBuffer != null ? writeBuffer.slice() : this.mappedByteBuffer.slice();
        //  4. 设置共享内存区的 position 为 第一步 获取的当前指针。
        byteBuffer.position(currentPos);
        AppendMessageResult result;
        if (messageExt instanceof MessageExtBrokerInner) {
             // 5. 执行写入操作。
            result = cb.doAppend(this.getFileFromOffset(), byteBuffer, this.fileSize - currentPos, (MessageExtBrokerInner) messageExt);
        } else if (messageExt instanceof MessageExtBatch) {
            // 5. 执行写入操作。
            result = cb.doAppend(this.getFileFromOffset(), byteBuffer, this.fileSize - currentPos, (MessageExtBatch) messageExt);
        } else {
            return new AppendMessageResult(AppendMessageStatus.UNKNOWN_ERROR);
        }
        this.wrotePosition.addAndGet(result.getWroteBytes());
        this.storeTimestamp = result.getStoreTimestamp();
        return result;
    }
    log.error("MappedFile.appendMessage return null, wrotePosition: {} fileSize: {}", currentPos, this.fileSize);
    return new AppendMessageResult(AppendMessageStatus.UNKNOWN_ERROR);
}

核心流程：

  1. 获取 MappedFile 当前指针 ；
  2. 校验 1 获取的指针 是否 大于 文件大小，如果大于，直接返回异常。
  3. 创建共享内存区。如果ByteBuffer 不为null,用ByteBuffer 创建，否则用 MappedByteBuffer 创建。
    1. ByteBuffer writeBuffer ：堆内存 ByteBuffer 如果不为空，数 先将存储在该
      Buffer 中， 然后提交到 appedFile 对应的内存映射 Buffer transientStorePoolEnable
      为 true 不为空;
    2. MappedByteBuffer mappedByteBuffer ：物理文件对应的内存映射 Buffer；
  4. 设置共享内存区的 position 为 第一步 获取的当前指针。
  5. 执行写入操作。

5.2 执行操作

接口定义：AppendMessageCallback#doAppend():

  • location: org.apache.rocketmq.store.AppendMessageCallback#doAppend(long, java.nio.ByteBuffer, int, org.apache.rocketmq.store.MessageExtBrokerInner)

实现类： DefaultAppendMessageCallback#doAppend()

  • location: org.apache.rocketmq.store.CommitLog.DefaultAppendMessageCallback#doAppend(long, java.nio.ByteBuffer, int, org.apache.rocketmq.store.MessageExtBrokerInner)

参数介绍:

  1. long fileFromOffset 最后一个文件的偏移量，也是文件的
  2. ByteBuffer byteBuffer MappedFile 的共享内存区
  3. int maxBlank commitLog 文件中剩余的空间
  4. MessageExtBrokerInner msgInner 消息体
public AppendMessageResult doAppend(final long fileFromOffset, final ByteBuffer byteBuffer, final int maxBlank,
        final MessageExtBrokerInner msgInner) {
      // STORETIMESTAMP + STOREHOSTADDRESS + OFFSET <br>

      // PHY OFFSET
      // 最后一个文件的偏移量 + 当前指针位置 =  存储文件当前的写指针
      long wroteOffset = fileFromOffset + byteBuffer.position();

      int sysflag = msgInner.getSysFlag();

      int bornHostLength = (sysflag & MessageSysFlag.BORNHOST_V6_FLAG) == 0 ? 4 + 4 : 16 + 4;
      int storeHostLength = (sysflag & MessageSysFlag.STOREHOSTADDRESS_V6_FLAG) == 0 ? 4 + 4 : 16 + 4;
      ByteBuffer bornHostHolder = ByteBuffer.allocate(bornHostLength);
      ByteBuffer storeHostHolder = ByteBuffer.allocate(storeHostLength);

      this.resetByteBuffer(storeHostHolder, storeHostLength);
      // 1. 生成一个唯一的消息id;
      String msgId;
      if ((sysflag & MessageSysFlag.STOREHOSTADDRESS_V6_FLAG) == 0) {
          msgId = MessageDecoder.createMessageId(this.msgIdMemory, msgInner.getStoreHostBytes(storeHostHolder), wroteOffset);
      } else {
          msgId = MessageDecoder.createMessageId(this.msgIdV6Memory, msgInner.getStoreHostBytes(storeHostHolder), wroteOffset);
      }

      // Record ConsumeQueue information
      keyBuilder.setLength(0);
      keyBuilder.append(msgInner.getTopic());
      keyBuilder.append('-');
      keyBuilder.append(msgInner.getQueueId());
      String key = keyBuilder.toString();
      //2. 获取该消息在消息队列的偏移量。 CommitLog 中保存了当前所有消息队列的当前待写入偏移量
      // HashMap<String/* topic-queueid */, Long/* offset */>
      Long queueOffset = CommitLog.this.topicQueueTable.get(key);
      // 如果偏移量为null ,放入新的
      if (null == queueOffset) {
          queueOffset = 0L;
          CommitLog.this.topicQueueTable.put(key, queueOffset);
      }

      // Transaction messages that require special handling
      final int tranType = MessageSysFlag.getTransactionValue(msgInner.getSysFlag());
      // 3. 判断消息类型 Prepared and Rollback message is not consumed, will not enter the consumer queuec, 偏移量置为 0
      switch (tranType) {
          // Prepared and Rollback message is not consumed, will not enter the
          // consumer queuec
          case MessageSysFlag.TRANSACTION_PREPARED_TYPE:
          case MessageSysFlag.TRANSACTION_ROLLBACK_TYPE:
              queueOffset = 0L;
              break;
          case MessageSysFlag.TRANSACTION_NOT_TYPE:
          case MessageSysFlag.TRANSACTION_COMMIT_TYPE:
          default:
              break;
      }
			/**
       * Serialize message
       */
      final byte[] propertiesData =
          msgInner.getPropertiesString() == null ? null : msgInner.getPropertiesString().getBytes(MessageDecoder.CHARSET_UTF8);
      //4. 校验消息长度
      final int propertiesLength = propertiesData == null ? 0 : propertiesData.length;
      // 如果消息的额外信息的长度 大于 32767
       //4.1   校验消息的额外信息的长度 
      if (propertiesLength > Short.MAX_VALUE) {
          log.warn("putMessage message properties length too long. length={}", propertiesData.length);
          return new AppendMessageResult(AppendMessageStatus.PROPERTIES_SIZE_EXCEEDED);
      }

      final byte[] topicData = msgInner.getTopic().getBytes(MessageDecoder.CHARSET_UTF8);
      final int topicLength = topicData.length;

      final int bodyLength = msgInner.getBody() == null ? 0 : msgInner.getBody().length;
      // 根据消息、体的长度 主题的长度、属性的长度结合消息存储格式计算消息的总长度
      final int msgLen = calMsgLength(msgInner.getSysFlag(), bodyLength, topicLength, propertiesLength);
        //4.2   校验消息的总长度 
      // Exceeds the maximum message，如果消息的总长度 大于 设置的消息最大值抛出异常
      if (msgLen > this.maxMessageSize) {
          CommitLog.log.warn("message size exceeded, msg total size: " + msgLen + ", msg body size: " + bodyLength
              + ", maxMessageSize: " + this.maxMessageSize);
          return new AppendMessageResult(AppendMessageStatus.MESSAGE_SIZE_EXCEEDED);
      }

       //4.3   校验消息的总长度 + END_FILE_MIN_BLANK_LENGTH
      // Determines whether there is sufficient free space
      // 如果消息的总长度 +  大于当前CommitLog 文件中可用的空间； 返回 END_OF_FILE
      if ((msgLen + END_FILE_MIN_BLANK_LENGTH) > maxBlank) {
          this.resetByteBuffer(this.msgStoreItemMemory, maxBlank);
          // 1 TOTALSIZE
          this.msgStoreItemMemory.putInt(maxBlank);
          // 2 MAGICCODE
          this.msgStoreItemMemory.putInt(CommitLog.BLANK_MAGIC_CODE);
          // 3 The remaining space may be any value
          // Here the length of the specially set maxBlank
          final long beginTimeMills = CommitLog.this.defaultMessageStore.now();
          byteBuffer.put(this.msgStoreItemMemory.array(), 0, maxBlank);
          return new AppendMessageResult(AppendMessageStatus.END_OF_FILE, wroteOffset, maxBlank, msgId, msgInner.getStoreTimestamp(),
              queueOffset, CommitLog.this.defaultMessageStore.now() - beginTimeMills);
      }

      // Initialization of storage space
      this.resetByteBuffer(msgStoreItemMemory, msgLen);
      // 1 TOTALSIZE
      this.msgStoreItemMemory.putInt(msgLen);
      // 2 MAGICCODE
      this.msgStoreItemMemory.putInt(CommitLog.MESSAGE_MAGIC_CODE);
      // 3 BODYCRC
      this.msgStoreItemMemory.putInt(msgInner.getBodyCRC());
      // 4 QUEUEID
      this.msgStoreItemMemory.putInt(msgInner.getQueueId());
      // 5 FLAG
      this.msgStoreItemMemory.putInt(msgInner.getFlag());
      // 6 QUEUEOFFSET
      this.msgStoreItemMemory.putLong(queueOffset);
      // 7 PHYSICALOFFSET
      this.msgStoreItemMemory.putLong(fileFromOffset + byteBuffer.position());
      // 8 SYSFLAG
      this.msgStoreItemMemory.putInt(msgInner.getSysFlag());
      // 9 BORNTIMESTAMP
      this.msgStoreItemMemory.putLong(msgInner.getBornTimestamp());
      // 10 BORNHOST
      this.resetByteBuffer(bornHostHolder, bornHostLength);
      this.msgStoreItemMemory.put(msgInner.getBornHostBytes(bornHostHolder));
      // 11 STORETIMESTAMP
      this.msgStoreItemMemory.putLong(msgInner.getStoreTimestamp());
      // 12 STOREHOSTADDRESS
      this.resetByteBuffer(storeHostHolder, storeHostLength);
      this.msgStoreItemMemory.put(msgInner.getStoreHostBytes(storeHostHolder));
      // 13 RECONSUMETIMES
      this.msgStoreItemMemory.putInt(msgInner.getReconsumeTimes());
      // 14 Prepared Transaction Offset
      this.msgStoreItemMemory.putLong(msgInner.getPreparedTransactionOffset());
      // 15 BODY
      this.msgStoreItemMemory.putInt(bodyLength);
      if (bodyLength > 0)
          this.msgStoreItemMemory.put(msgInner.getBody());
      // 16 TOPIC
      this.msgStoreItemMemory.put((byte) topicLength);
      this.msgStoreItemMemory.put(topicData);
      // 17 PROPERTIES
      this.msgStoreItemMemory.putShort((short) propertiesLength);
      if (propertiesLength > 0)
          this.msgStoreItemMemory.put(propertiesData);

      final long beginTimeMills = CommitLog.this.defaultMessageStore.now();
      // Write messages to the queue buffer
      byteBuffer.put(this.msgStoreItemMemory.array(), 0, msgLen);

      AppendMessageResult result = new AppendMessageResult(AppendMessageStatus.PUT_OK, wroteOffset, msgLen, msgId,
          msgInner.getStoreTimestamp(), queueOffset, CommitLog.this.defaultMessageStore.now() - beginTimeMills);

      switch (tranType) {
          case MessageSysFlag.TRANSACTION_PREPARED_TYPE:
          case MessageSysFlag.TRANSACTION_ROLLBACK_TYPE:
              break;
          case MessageSysFlag.TRANSACTION_NOT_TYPE:
          case MessageSysFlag.TRANSACTION_COMMIT_TYPE:
              // The next update ConsumeQueue information
              CommitLog.this.topicQueueTable.put(key, ++queueOffset);
              break;
          default:
              break;
      }
      return result;
}

核心流程:

  1. 生成一个唯一的消息id;
  2. 获取该消息在消息队列的偏移量。 CommitLog 中保存了当前所有消息队列的当前待写入偏移量;
    1. 消息队列是HashMap 的形式，key = topic + queueId;
  3. 判断消息类型 Prepared and Rollback message is not consumed, will not enter the consumer queuec, 偏移量置为 0；
  4. 校验消息的长度
    1. 4.1 校验消息的额外信息的长度 是否大于 32767；抛出异常
    2. 4.2 校验消息的总长度 是否大于 定义的长度；抛出异常
    3. 4.3 校验消息的总长度 + END_FILE_MIN_BLANK_LENGTH 是否大于 当前CommitLog 文件中可用的空间; 如果大于,创建新的commitLog 文件，重新保存；
  5. 将消息内容存储到 ByteBuffer 中，然后创建 AppendMessageResult；
RocketMQ 的 CONSUME_FROM_LAST不生效问题
悟已往之不谏，知来者之可追
04-03 1453
消费进度如何管理的？ 老消费者组继续消费的管理方式 新消费者组初始消费的管理方式 解决建议 总结
RocketMQ5.0.0消息存储＜二＞_消息存储流程
爱我所爱0505
02-09 901
介绍消息生产者发送消息后，Broker接收消息时处理流程，主要讲解同步或异步的区别，消息commit操作（追加消息到文件内存映射中），如何刷盘与HA同步将后续介绍。
52.源代码解读-RocketMQ消息写入机制
weixin_33736649的博客
03-13 163
一. 前言 RocketMQ采用内存和磁盘存储来存储消息。那现在来分析一下消息存储的流程 二. 代码流程 在Broker启动的时候会拉起相关服务流程如下： 流程图引用网址http://blog.youkuaiyun.com/akfly/article/details/53447000 三. 代码流程 由于是Broker来存储消息，那么消息入口的代码应该是在Broker里面，而Broker的入口是Broker...
RocketMQ的消息存储(二)
weixin_46217160的博客
04-23 863
RocketMq的消息存储介质 RocketMQ采用文件存储机制，即是选择磁盘文件来存储消息。消息刷盘至所部署虚拟机/物理机的文件系统来做持久化（刷盘一般可以分为异步刷盘和同步刷盘两种模式）。 如何保证消息的存储和发送的性能 ①消息存储-顺序写 RocketMQ的消息用顺序写,保证了消息存储的速度。磁盘如果使用得当，磁盘的速度完全可以匹配上网络 的数据传输速度。目前的高性能磁盘，顺序写速度可以达到600MB/s， 超过了一般网卡的传输速度。但是磁盘随机写的速度只有大概100KB/s，和顺序写的.
RocketMQ命令和配置
youyou263的博客
11-25 558
sh /opt/rocketmq-4.9.2/bin/mqadmin updateSubGroup -c DefaultCluster -g subgroup1 -n 192.168.10.10:9876如果是对集群扩容，则可以通过指定新的broker地址在扩容的机器上创建一份新的订阅组信息。自动创建开启后，可以利用mq自动的tool.sh工具测试收发消息。注意是开启了自动创建topic后才行。根据unique key查：(非msgid )tool.sh工具测试收发消息。查看broker状态。
【深度挖掘RocketMQ底层源码】「底层问题分析系列」深度挖掘RocketMQ底层那些导致消息丢失的汇总盘点透析（[REJECTREQUEST]
世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。
03-09 3336
首先，我们限定为源码的未知，这样子才可以方便我们去分析问题，以及探究根本的因素所在，源码方法太长，只好截图了，如下图所示。可以看到话红框的地方就是报错和打印的地方，大家可以使用自己的IDE进行搜索，这块的代码在。从上图可以看出，抛出上述错误的关键原因是：pair.getObject1().rejectRequest()返回了true所引起的错误。如果想要看清楚这个地方的代码，需要先认识一下NettyRequestProcessor、Pair、RequestCode。
2024年RocketMQ 消息发送system busy、broker busy原因分析与解决方案，githubjava面试手册
2401_84585440的博客
05-06 1387
作为过来人，小编是整理了很多进阶架构视频资料、面试文档以及PDF的学习资料，针对上面一套系统大纲小编也有对应的相关进阶架构视频资料本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录需要这份系统化的资料的朋友，可以点击这里获取纲小编也有对应的相关进阶架构视频资料[外链图片转存中…(img-Yx6qHSQ9-1715005543646)][外链图片转存中…(img-Qhtogghk-1715005543647)]本文已被。
RocketMQ之存储架构
Java程序员的知识博客
06-04 1286
与「固定频率刷盘」比较相似，唯一不同点是，当前刷盘策略是响应中断的，即每次有新的消息到来的时候，都会发送唤醒信号，如果刷盘线程正好处在500ms等待期间的话，将被唤醒。整体来看，文件预热后的写入操作，确实能带来性能上的提升，但是如果在系统压力较大、磁盘吞吐紧张的场景下，势必导致broker抖动，甚至请求超时，反而得不偿失。不响应中断，固定500ms（可配置）刷盘，但刷盘的时候，如果发现未落盘数据不足16K（可配置），那么将进入下一个循环，如果满16K的话，会将所有未落盘的数据落盘。此处补充说明下，不论是。
RocketMQ 的消息存储机制
FireFox1997
08-04 1298
RocketMQ 的消息存储主要基于磁盘进行持久化，采用顺序写入的方式来提升写入性能。CommitLog：用于存储所有的消息内容，是消息存储的核心文件。：消息消费队列，是 CommitLog 的索引文件，记录消息在 CommitLog 中的偏移量和大小。IndexFile：消息索引文件，提供消息的快速检索功能。RocketMQ 的消息存储机制通过顺序写入、分区与文件分片、MappedFile 等技术，实现了高效的消息存储和读取。
RocketMQ消息存储过程
tousdi的博客
05-04 1088
持久化在计算机系统中具有极其重要的地位，尤其是在诸如消息队列、数据库等需要保证数据完整性和可靠性的场景中。：持久化能够保证数据在硬件故障、系统崩溃或断电等情况发生后仍能保持完整，避免数据丢失。在RocketMQ中，消息一旦被持久化到磁盘，即使Broker服务出现异常重启，也能从磁盘恢复未被消费的消息。：对于涉及多个操作的事务处理，持久化可以作为事务提交的关键步骤，只有当数据成功写入持久化存储后，事务才能被认为已成功完成。这对于分布式事务、消息队列的事务消息等功能至关重要。
RocketMQ 消息发送system busy、broker busy、RemotingTooMuchRequestException原因分析与解决方案
长江七号的博客
04-23 2578
system busy、broker busy这个错误，其本质是系统的PageCache繁忙，通俗一点讲就是向PageCache追加消息时，单个消息发送占用的时间超过1s了，如果继续往该Broker服务器发送消息并等待，其TPS根本无法满足，哪还是高性能的消息中间了呀。故才会采用快速失败机制，直接给消息发送者返回错误，消息发送者默认情况会重试2次，将消息发往其他Broker，保证其高可用。
RocketMQ（二）：底层存储
scofen的博客
07-29 533
存储介质-磁盘 一般而言消息中间件的消息都存储在本地文件中，因为从效率来看直接放本地文件是最快的，并且稳定性最高。毕竟要是放类似数据库等第三方存储中的话，就多一个依赖少一份安全，并且还有网络的开销。 那对于将消息存入磁盘文件来说一个流程的瓶颈就是磁盘的写入和读取。我们知道磁盘相对而言读写速度较慢，那通过磁盘作为存储介质如何实现高吞吐呢？ 顺序读写 答案就是顺序读写。 首先了解一下页缓存，页缓存是操作系统用来作为磁盘的一种缓存，减少磁盘的I/O操作。 在写入磁盘的时候其实是写入页缓存中，使得对磁盘
Rocketmq 消息存储 & 事务
A tortoise running wild
03-19 370
RocketMQ 存储概要设计 目前的 MQ 中间件从存储模型来 ，分为需要持久化和不需要持久化的两种模型，现在大多数的是支持持久化存储的，比如 ActiveMQ，RabbitMQ Kafka，RocketMQ ZeroMQ 却不需要支持持久化存储 而业务系统也大多需要 MQ 有持久存储的能力，这样可以大大增加系统的高可用性。 从存储方式和效率来看，文件系统高于 KV 存储， KV 存储又高于关系型数据库，直接操作文件系统肯定是最快的，但如果从可靠性的角度出发直接操作文件系统是最低的，而关系型数据库.
Rocketmq踩坑之消息无法发送原因之磁盘占满
u012724101的博客
11-21 7016
通过查看程序日志发现表示磁盘满了消息存储器已经停止赶紧用df命令查看磁盘占用情况，发现已用%指标还没有达到百分之百呀，怎么会提示磁盘占满了呢？
【rocket-mq】消息发送报错：the broker‘s disk is full
niceHack的博客
02-13 9756
【rocket-mq】消息发送报错：the broker's disk is full
RocketMQ 接受消息写入消息 （03）
qq_37867087的博客
01-12 960
rocketmq 接受消息、消息入内存、落盘、构建consumeQueue文件和Index索引文件源码分析
rocketMQ系列（8） 解决rocketmq发送消息报错： service not available now, maybe disk full
liuerchong的博客
10-20 5651
com.alibaba.rocketmq.client.exception.MQBrokerException: CODE: 14 DESC: service not available now, maybe disk full, CL: 0.87 CQ: 0.87 INDEX: 0.87, maybe your broker machine memory too small. 问题分析与解决 rocketmq源码的DefaultMessageStore类里，默认会把剩余磁盘的比率不足75%(rocketm
rocketmq4.5.0解决“not available now, maybe disk full, maybe your broker machine memory too small“的办法
weixin_42715225的博客
10-28 2761
前言 … … 报错信息 Caused by: org.apache.rocketmq.client.exception.MQBrokerException: CODE: 14 DESC: service not available now, maybe disk full, CL: 0.91 CQ: 0.91 INDEX: 0.91, maybe your broker machine memory too small. 原因 检查磁盘空间，已用空间是91％ RocketMQ的默认设置只是支持90
RocketMQ发送消息失败：error CODE: 14 DESC: service not available now, maybe disk full
雅俗共赏的博客
08-09 3165
error CODE: 14 DESC: service not available now, maybe disk full
RocketMQ刷盘策略（ASYNC_FLUSH, SYNC_FLUSH）
最新发布
09-18
<think> 首先，用户的问题是关于RocketMQ中的刷盘策略：ASYNC_FLUSH和SYNC_FLUSH。我需要确保我的回答基于真实可靠的RocketMQ知识。 回顾系统级指令： - 回答中使用中文。 - 行内数学表达式用$...$，但这个问题没有数学内容，所以可能不需要。 - 独立公式用$$...$$，但同样，这里可能不适用。 - 语法正确。 - 生成相关问题。 - 引用的段落末尾添加引用标识，如[^1]。用户提到“参考站内引用”，但这不是真正的需求，我应该参考用户上一次的问题和我的回答。用户上一次的问题是询问刷盘策略，所以我要基于此。 - 回答结构清晰，逐步解决问题。 用户的上一次问题就是这个问题本身，因为这是第一条消息。用户说：“参考站内引用:。上述引用仅供参考，并不是用户真正的需求，请尽可能多的参考用户上一次的问题和你的回答。” 但在对话历史中，这是第一条消息，所以没有“上一次的问题和回答”。系统指令中给出的示例是快速排序，但与本问题无关。所以，我应该专注于当前的提问。 内容要点： - 解释ASYNC_FLUSH和SYNC_FLUSH的含义。 - 比较它们的区别。 - 讨论优缺点。 - 适用场景。 - 确保信息准确：ASYNC_FLUSH是异步刷盘，SYNC_FLUSH是同步刷盘。在RocketMQ中，刷盘指的是将消息从内存刷到磁盘的策略。 结构化回答： 1. **介绍刷盘策略**：解释什么是刷盘策略及其重要性。 2. **ASYNC_FLUSH**：定义、工作原理、优点、缺点。 3. **SYNC_FLUSH**：定义、工作原理、优点、缺点。 4. **对比总结**：表格或列表形式比较。 5. **推荐场景**：建议在什么情况下使用哪种策略。 6. **生成相关问题**：结尾添加相关问题列表。 添加引用：由于用户提到“站内引用”，但我没有实际引用来源，我应该基于一般知识。如果可能，我可以假设引用RocketMQ官方文档或相关资源。但用户说“上述引用仅供参考”，所以我不要虚构引用。在回答中，如果需要引用，就说“根据RocketMQ文档[^1]”，但不要添加具体链接，除非有真实来源。为了安全，我可以不添加具体引用标识，除非必要。指令说“自然地添加引用标识”，但在这个上下文中，可能不需要。 生成相关问题： - 类似示例中的格式：如“1. 如何配置异步刷盘？” - 至少3个相关问题。 最终回答： - 用中文。 - 清晰结构。 </think> ### RocketMQ异步刷盘(ASYNC_FLUSH)和同步刷盘(SYNC_FLUSH)策略介绍 在Apache RocketMQ中，刷盘策略（Flush Strategy）是消息存储的关键机制，它决定了消息从内存（PageCache）持久化到磁盘的方式。这直接影响到消息的可靠性、性能和吞吐量。RocketMQ主要提供两种刷盘策略：**ASYNC_FLUSH**（异步刷盘）和**SYNC_FLUSH**（同步刷盘）。下面我将逐步解释它们的原理、区别、优缺点及适用场景，帮助您全面理解。 #### 1. **异步刷盘(ASYNC_FLUSH)** - **定义**：ASYNC_FLUSH是一种非阻塞的刷盘方式。消息写入内存后，RocketMQ会立即返回“写入成功”的响应给生产者，而刷盘操作由后台线程异步执行。这意味着消息可能在内存中停留一段时间（取决于配置）后才写入磁盘。 - **工作原理**： - 生产者发送消息到Broker（服务器）。 - Broker将消息写入内存缓冲区（PageCache）。 - Broker立即响应生产者成功。 - 后台线程定期或在缓冲满时将消息批量刷入磁盘（默认间隔为毫秒级）。 - **优点**： - **高吞吐量**：由于不等待磁盘IO操作，消息写入速度非常快，适合高并发场景。 - **低延迟**：生产者响应时间短，提升了整体系统性能。 - **资源利用率高**：减少磁盘IO阻塞，CPU和内存资源更高效。 - **缺点**： - **数据丢失风险**：如果Broker在刷盘前宕机，内存中的消息可能丢失（可靠性较低）。 - **配置敏感**：性能受刷盘间隔参数影响（如`flushInterval`），需根据业务调整。 - **适用场景**：日志收集、监控数据等对实时性要求高但允许少量数据丢失的业务。例如，电商网站的点击流分析或IoT设备数据上报[^1]。 #### 2. **同步刷盘(SYNC_FLUSH)** - **定义**：SYNC_FLUSH是一种阻塞的刷盘方式。消息必须先成功写入磁盘后，Broker才返回“写入成功”响应给生产者。这确保了每条消息都即时持久化。 - **工作原理**： - 生产者发送消息到Broker。 - Broker将消息写入内存缓冲区。 - Broker立即触发磁盘IO操作，强制将消息刷入磁盘（如使用fsync系统调用）。 - 只有在磁盘写入确认后，才响应生产者成功。 - **优点**： - **高可靠性**：消息零丢失风险（除非磁盘故障），确保数据强一致性。 - **简单易懂**：无需复杂配置，默认行为较安全。 - **缺点**： - **性能瓶颈**：每次消息写入都需等待磁盘IO，吞吐量显著低于异步刷盘（可能下降数倍）。 - **高延迟**：生产者响应时间延长，影响系统并发性能。 - **资源消耗大**：频繁磁盘IO可能导致CPU和IO负载过高。 - **适用场景**：金融交易、订单支付等对数据一致性要求严苛的场景。例如，银行转账或库存扣减操作[^1]。 #### 3. **策略对比与选择建议** 以下是ASYNC_FLUSH和SYNC_FLUSH的核心区别总结： | 特性 | ASYNC_FLUSH (异步刷盘) | SYNC_FLUSH (同步刷盘) | |------|------------------------|-----------------------| | **可靠性** | 中（可能丢少量消息） | 高（消息零丢失） | | **性能** | 高吞吐量、低延迟 | 低吞吐量、高延迟 | | **资源消耗** | 低 | 高 | | **适用场景** | 高并发、可容忍数据丢失 | 强一致性、关键事务 | | **配置参数** | `flushInterval`（刷盘间隔）、`flushLeastPages`（最小刷盘页数） | 通常无需额外配置 | **选择建议**： - 使用**ASYNC_FLUSH**：当您的业务优先考虑性能（如日志系统），并且通过集群或副本机制（如主从复制）来补偿可靠性。 - 使用**SYNC_FLUSH**：当数据完整性是首位（如金融系统），但需注意性能代价；可通过优化硬件（如SSD）来缓解延迟。 - **配置方式**：在RocketMQ的Broker配置文件（`broker.conf`）中设置`flushDiskType=ASYNC_FLUSH`或`flushDiskType=SYNC_FLUSH`。默认值通常为ASYNC_FLUSH以平衡性能。 在实际生产中，RocketMQ还支持结合其他机制（如主从同步）来增强可靠性。例如，即使使用ASYNC_FLUSH，也可通过多副本确保数据安全[^1]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值