下面是 CORBA Notification 规范中处理方式： (1). RejectNewEvents 拒绝新来的消息，吐 Producer 迒回 RejectNewEvents 错诨码。 (2). 挄照特定策略丢弃已有消息 a) AnyOrder - Any event may be discarded on overflow. This is the default setting 当消息丌能在内存 Cache 命中时，要丌可避免的访问磁盘，会产生大量读 IO，读 IO 的吞吏量直接决定了 消息堆积后的访问能力。 评估消息堆积能力主要有以下四点： (1). 消息能堆积多少条，多少字节？即消息的堆积容量。 (2). 消息堆积后，収消息的吞吏量大小，是否会叐堆积影响？ 项目开源主页：https://github.com/alibaba/RocketMQ 9 (3). Message Id 查询消息 消息所属Broker地址 8Byte Commit Log Offset 8Byte 图表 7-2 Message Id 组成 MsgId 总共 16 字节，包含消息存储主机地址，消息 Commit Log offset。从 MsgId 中解析出 Broker 的地址和 Commit Log 的偏秱地址，然后挄照存储格式所在位置消息 buffer 解析成一个完整的消息。

当前最新的物理偏移量之间的差距查过 内存的 40%，下一次拉取会往从节点发送（当然前提是 slaveReadEnable = true）。 2. 当从节点开始接管消息消费时，下一次拉取请求一定会往从节点发送码？答案也是不一 定：  如果待拉取的消息偏移量与从节点最新的物理偏移量之间的差距超过内存的 30%，下 一次拉取请求还是会发往从节点。  如果待拉取的消息偏移量与从节点最新的物理偏移量之际的差距少于内存的 bytes2string(input.array()); } 首先结合该方法的调用上下文，先解释一下该方法三个入参的含义：  ByteBuffer input 用来存放 offsetMsgId 的字节缓存区(NIO 相关的基础知识)  ByteBuffer addr 当前 Broker 服务器的 IP 地址与端口号，即通过解析 offsetMsgId 从而得到消息服务 器的地址信息。 success 是发送成功。 本文来自『中间件兴趣圈』公众号，仅作技术交流，未授权任何商业行为。 153 > 1.16 RocketMQ 消息轨迹-设计篇  contextCode 消费状态码，可选值：SUCCESS,TIME_OUT,EXCEPTION,RETURNNULL, FAILED。 二、记录消息轨迹 消息中间件的两大核心主题：消息发送、消息消费，其核心载体就是消息，消息轨迹（消

ffset, storeTimestamp。 2.2.3 事物状态表 事物状态表是有 MapedFileQueue 将多个文件组成一个连续的队列，它的存储单元是定 长为 24 个字节的数据， tranStateTableOffset 可以认为是事物状态消息的个数，索引偏移量， 它的值是 tranStateTable.getMaxOffset() / TSStoreUnitSize 文件地址：${user.home} \store\consumequeue\${topicName}\${queueId}\${fileName} consume queue 中存储单元是一个 20 字节定长的数据，是顺序写顺序读 （1） commitLogOffset 是指这条消息在 commitLog 文件实际偏移量 （2） size 就是指消息大小 （3） 消息 tag 的哈希值 home} \store\${commitlog}\${fileName} 一个消息存储单元长度是不定的，顺序写但是随机读 消息存储结构： = 4 //4 个字节代表这个消息的大小 + 4 //四个字节的 MAGICCODE = daa320a7 + 4 // 消息体 BODY CRC 当 broker 重启 recover 时会校验 +