RocketMq

RocketMq消费失败时处理机制 消费端处理机制 消费者消费失败后，会把消费发回给 Broker 进行处理。下图是客户端处理流程： 注意点： 广播消费模式下，消息失败会直接丢弃，不会发送回Broke

在使用 RocketMQ 的过程中，有时候我们会看到下面的日志： 这是因为 RocketMQ 触发了流量控制。生产者把消息写入 Broker，Consumer 从 Broker 拉取消息。Broker

解决方案 如果消费者数量小于Topic的分区数(RocketMq的Topic队列数)，那么增大消费者数量直到分区数，这是可以提高消费速度。否则，就没有效果。 增加消费者数量一定会提高消费速度吗？(小于

RocketMq架构图 RocketMq消息不丢失 要想保证消息不丢失，需要从以下几个方面考虑： Producer 发送消息 Broker 主从切换、保存消息 Consumer 消费消息 发送端考虑

定时消息(4.x) 在 RocketMQ 4.x 及更早版本中，延迟消息仅支持预设的 18 个固定延迟级别（如 1s、5s、10s、30s 等），用户无法自定义任意延迟时间。 实现原理：每个延迟级别对

文件刷盘机制 RocketMQ的存储与读写是基于JDK NIO的内存映射机制（MappedByteBuffer）的，消息存储时首先将消息追加到内存，再根据配置的刷盘策略在不同时间进行刷写磁盘。 如果是

RocketMQ存储路径为${ROCKET_HOME}/store，如图所示： commitlog：消息存储目录。 config：运行期间一些配置信息，主要包括下列信息。 consumerFilter

RocketMQ通过使用内存映射文件来提高IO访问性能，无论是CommitLog、ConsumeQueue还是IndexFile，单个文件都被设计为固定长度，如果一个文件写满以后再创建一个新文件，文件

任何消息队列，消息存储的设计都是最核心、最重要的功能，存储的核心是IO的性能，而关于RocketMq, 以下就是这个模块的重要内容： RocketMQ存储概要设计、消息发送存储流程 存储文件组织与内存