RocketMQ采用文件型、顺序写的高性能存储设计，核心分三类文件。首先是CommitLog，所有消息统一顺序写入，不分主题，保证极致写入性能，是消息存储核心；其次是ConsumeQueue，消费队列，按主题+队列存储消息的物理偏移量、大小等索引，消费时快速定位；最后是IndexFile，索引文件，用于按消息Key、时间戳查询。所有文件采用固定长度的内存映射机制，避免随机IO，读写效率极高。消息先写页缓存再异步刷盘，兼顾性能和可靠性，这种混合存储架构让RocketMQ既能支撑高吞吐，又能快速消费消息。
RocketMQ通过分区（队列）有序+严格绑定实现消息顺序，分全局有序和分区有序。生产者将需要有序的消息发送到同一个消息队列，保证FIFO写入；消费者采用集群单线程消费模式，一个队列只绑定一个消费者，严格按队列顺序拉取处理。全局有序需将主题设为单队列，分区有序用多队列兼顾并发。顺序消费会牺牲部分并行度，适合订单、交易等强顺序场景。RocketMQ通过队列锁、消费位点控制，彻底避免乱序，是分布式消息中顺序保障的成熟方案。
RocketMQ负载均衡分生产者和消费者两端，全程自动化。生产者默认轮询主题下的所有消息队列，将消息均匀分发到不同Broker队列，实现写入负载均衡。消费者集群模式下，会将主题的队列平均分配给组内消费者，一个队列仅对应一个消费者，避免重复消费；消费者增减时，自动重新分配队列，保证负载均衡。支持平均、随机、一致性哈希等多种分配策略，可自定义适配场景。负载均衡无中心化协调，轻量高效，让消息收发均匀分散，提升集群整体吞吐。
RocketMQ对消费失败的消息自动重试+死信收尾，保障消费稳定性。消费者处理异常时，消息会重新回Broker，按延迟级别重试，默认最多16次，重试间隔逐级递增。超过最大重试次数仍失败，消息自动转入死信队列（DLQ），死信主题自动创建，前缀%DLQ%。死信消息不会再自动消费，需人工排查处理。重试机制解决临时故障，死信队列处理永久异常消息，两者结合避免消息丢失、阻塞正常消费，无需手动配置，开箱即用。
RocketMQ事务消息是两阶段提交+回查的半消息机制，保证分布式事务最终一致。第一阶段生产者发送半消息，Broker暂存不投递；第二阶段执行本地事务，根据结果提交/回滚半消息。若Broker未收到结果，会主动回查生产者事务状态，最终决定投递或删除。事务消息存储在独立队列，不影响普通消息。该机制无业务侵入，解决了分布式系统中本地事务与消息发送的原子性问题，适配订单、支付等核心交易场景。
RocketMQ提供TAG标签过滤和SQL92属性过滤两种方式，精准筛选消息。TAG过滤是基础，生产者发送消息时指定标签，消费者订阅时匹配标签，Broker端快速过滤，性能极高。SQL过滤基于消息属性，支持大于、小于、等于等逻辑判断，适合复杂筛选，在消费者端过滤，灵活性强。过滤规则存储在Broker，消费时自动匹配，无需业务代码处理。两种方式按需选择，TAG适合简单分类，SQL适合复杂条件，满足不同消息筛选需求。
RocketMQ从生产、存储、消费全链路保障消息可靠。生产者采用同步发送+重试机制，确保消息送达Broker；Broker开启同步双写、异步刷盘，消息持久化后才返回确认，防止宕机丢失；消费者手动提交消费位点，处理完成后再确认，避免未处理完丢失。同时支持消息重试、死信队列、副本备份，多重机制兜底。所有环节自带确认机制，消息不丢不乱，生产环境默认配置即可满足高可靠需求，适配金融、电商等核心业务。
NameServer是RocketMQ的轻量级注册中心+协调中心，无单点故障。它负责管理Broker集群元数据，记录所有Broker、主题、队列的地址信息；Broker定时向NameServer上报心跳，维持在线状态；生产者/消费者从NameServer拉取路由信息，定位目标Broker。NameServer集群部署，节点相互独立，不通信，降低复杂度。它不参与消息收发，仅做路由管理，即便宕机也不影响已建立的连接，是RocketMQ集群轻量化、高可用的核心组件。
RocketMQ通过固定延迟级别实现延时消息，原生支持18个预设级别（1s~2h）。生产者发送消息时指定delayTimeLevel参数，Broker不立即投递，将消息存入延时队列，到达设定时间后才转入正常队列供消费。延时消息存储在独立CommitLog，时间轮算法精准调度，性能无损耗。该功能无需第三方组件，开箱即用，适合订单超时、验证码过期等场景。虽然不支持自定义秒级，但预设级别覆盖绝大多数业务，稳定可靠。
Broker是RocketMQ的核心工作节点，负责消息全生命周期管理。主要职责：接收生产者消息，持久化到CommitLog；响应消费者拉取请求，投递消息；管理消息队列、副本同步、延时消息、重试队列；向NameServer上报状态和元数据；处理事务消息回查、死信消息存储。Broker分Master和Slave角色，Master负责读写，Slave同步数据做备份。单个Broker支撑高吞吐读写，集群部署分散压力，是消息存储、转发、治理的核心载体。
RocketMQ消费者采用主动拉取（Pull） 模式，自主控制消费速度。消费者定时向Broker发起拉取请求，可配置批量拉取数量、等待时间，平衡实时性和吞吐。拉取采用长轮询优化，Broker无消息时短暂挂起请求，有消息立即返回，减少无效请求。消费者本地缓存消息，串行/并行处理，处理完成后提交位点。拉取模式由消费者主导，不会被Broker压垮，适配不同性能的消费端，是高可用消费的核心设计。
消息压缩：生产者开启compressEnable，配置阈值，超过大小的消息自动用LZ4压缩，减少网络传输和存储开销，Broker/消费者自动解压。批量发送：生产者创建MessageBatch容器，聚合多条消息，一次性发送到Broker，减少网络请求次数。批量发送支持按条数、大小限制批次，避免超大消息。压缩和批量发送默认支持，无需复杂配置，能大幅提升小消息、高并发场景的吞吐性能，是生产必用优化手段。
RocketMQ内置消息轨迹+可视化监控，全程可观测。消息轨迹记录生产、投递、消费全链路状态，存储在独立主题，可通过控制台查询消息位置、失败原因。监控统计吞吐量、响应时间、消费堆积、重试次数等核心指标，集成Prometheus、Grafana可做大盘可视化。Broker、生产者、消费者自带Metrics上报，支持告警配置。轨迹和监控让消息流转透明化，快速排查丢失、重复、堆积问题，是运维核心工具。
RocketMQ无法杜绝重复，核心靠业务幂等性解决。网络波动、重试机制会导致消息重复投递，消费者处理时需做幂等校验：用消息唯一ID做去重标记，存入Redis/数据库，处理前查询是否已执行；利用数据库唯一索引约束，自动拦截重复数据；核心业务结合分布式锁，保证单消息仅处理一次。RocketMQ默认提供消息唯一键，配合业务幂等，简单高效，是解决重复消费的标准方案，无需修改中间件配置。
RocketMQ从生产、消费、Broker三端做流量控制，防止系统过载。生产者限制发送速度、并发量，避免压垮Broker；Broker配置主题消息写入速率、队列长度，触发限流快速失败；消费者控制拉取批量、线程数，限制消费速度，避免堆积。同时支持慢消费检测、队列限流、连接数管控，所有策略可动态配置。流量控制能有效防止流量突刺导致的集群崩溃，保证高并发下服务稳定，是生产环境必备的防护机制。
RocketMQ采用Master-Slave主备架构实现高可用，一个Master对应一到多个Slave。Master负责处理所有读写请求，Slave通过同步/异步复制Master数据，仅做备份。Master宕机时，Slave可手动/自动切换为Master，保证服务不中断。主备节点分散在不同物理机，避免单点故障。同步复制保证数据不丢失，异步复制提升性能。主备架构无复杂选举，部署简单，配合NameServer路由切换，实现集群故障自动转移，稳定可靠。
RocketMQ通过标准化协议+多语言SDK支持跨语言。核心采用TCP自定义协议，定义统一的消息格式、编解码规则，不绑定特定语言。官方提供Java、C++、Go、Python、Node.js等多语言SDK，不同语言的生产者、消费者遵循同一套协议交互。消息序列化支持JSON、二进制，跨语言解析无障碍。所有语言客户端接入同一集群，收发消息完全互通，无需额外适配，轻松实现多语言微服务架构下的消息通信。
消息回溯让消费者重新消费历史消息，用于数据修复、测试场景。使用方式：通过控制台/命令行指定消费组、主题，按时间点、位点、偏移量回溯。消费者会重置消费位点到目标位置，从该点重新拉取消息。回溯支持集群、广播模式，集群模式下所有消费者统一重置位点。回溯后不影响正常消息，历史消息重新消费完成后，自动恢复最新位点消费。该功能无需修改代码，一键操作，是数据纠错、日志重放的实用工具。
RocketMQ集群推荐多Master多Slave部署，最佳实践：NameServer集群至少2节点，无状态轻量；Broker按业务拆分集群，核心业务独立部署；Master和Slave跨机架/机房部署，避免单点；同步复制用于核心消息，异步复制用于高吞吐消息；主题合理设置队列数，匹配消费者并发；开启消息追踪、监控告警，禁用自动创建主题。集群横向扩展Broker提升吞吐，主备保证高可用，配合参数调优，支撑百万级TPS，是生产环境标准部署方案。
RocketMQ消息分发分生产者分发和消费者分发。生产者：轮询（默认）、随机、哈希、自定义队列策略，均匀分发到队列。消费者：集群模式下平均分配队列，广播模式全量分发所有消息；支持一致性哈希、就近路由等自定义策略。消息分发无中心化，基于队列做负载均衡，保证收发均匀。不同策略适配不同场景，轮询适合通用场景，哈希适合有序消息，广播适合全节点通知，灵活满足业务需求。
RocketMQ从三端杜绝消息丢失，针对性处理。生产者：用同步发送，失败重试，确认Broker接收成功；开启事务消息保证核心数据可靠。Broker：配置同步刷盘+同步双写，消息持久化到磁盘、副本同步完成后返回确认，防止宕机丢失。消费者：手动提交消费位点，消息处理完成后再提交，避免未处理完丢失。同时开启消息重试、死信队列，监控消费堆积。全链路确认+持久化+重试，三重保障，彻底解决消息丢失问题。
NameServer与Broker采用定时心跳+长连接通信，轻量高效。Broker启动后主动与所有NameServer建立长连接，每30秒发送心跳包，上报自身IP、主题、队列、状态等元数据；NameServer校验心跳，更新路由表，超过120秒未收到心跳则标记Broker下线。NameServer不主动推送路由，仅被动响应生产者/消费者的拉取请求。通信基于TCP自定义协议，无复杂交互，即便单个NameServer宕机，Broker仍能与其他节点通信，保证集群元数据稳定。
RocketMQ原生不支持绝对优先级，通过队列分级+队列绑定模拟实现。创建多个队列对应不同优先级（高、中、低），生产者按消息优先级发送到对应队列；消费者优先拉取高优先级队列的消息，高优先级消费完再处理低优先级。也可通过多消费组，给高优先级队列分配更多消费线程。这种方案无需改造中间件，简单可靠，满足大部分优先级业务场景，是RocketMQ实现消息优先级的标准方案。
RocketMQ默认18个延迟级别，自定义需修改Broker源码配置。修改MessageStoreConfig中的messageDelayLevel参数，添加自定义时间级别（如10s、30s、1h），重新编译部署Broker。自定义后，生产者指定新的级别值即可使用。注意自定义级别需所有Broker统一配置，否则不生效。该方式适合有特殊延时需求的业务，虽然需要修改配置，但稳定性不受影响，满足个性化延时场景。
平衡核心是分区有序+多队列并发。不追求全局有序，将业务按维度拆分到多个消息队列，每个队列内严格有序，多队列并行消费，提升并发度。生产者用哈希路由将同类有序消息发往同一队列，消费者单线程消费单个队列，多队列多线程并行。全局有序用单队列但牺牲并发，分区有序兼顾顺序和吞吐。RocketMQ通过队列锁、位点控制，在保证分区有序的前提下，最大化提升并发能力，是最优平衡方案。
大量小消息会降低吞吐，优化核心是批量聚合+压缩。生产者开启批量发送，聚合多条小消息为一个批次发送，减少网络请求；开启消息压缩，减小传输体积。Broker调小日志段文件，优化小消息存储索引。消费者批量拉取、批量处理，提升消费效率。还可自定义消息合并，将多条小消息封装为大消息发送，消费端拆分。聚合+压缩后，小消息场景吞吐提升数倍，完美解决高并发小消息瓶颈。
同步复制：Master写入消息后，必须等待Slave同步完成才返回确认，数据强一致，Master宕机Slave无数据丢失，但写入延迟高、吞吐低，适合金融、订单等核心可靠场景。异步复制：Master写入后立即返回确认，后台异步同步到Slave，写入延迟低、吞吐高，但Master宕机可能丢失少量未同步数据，适合日志、埋点等非核心场景。两者可按主题动态配置，平衡可靠性和性能，生产中核心业务用同步，普通业务用异步。
RocketMQ采用主题（Topic）+消息队列（Queue） 的核心模型。Topic是逻辑消息分类，对应一类业务消息，是生产者、消费者的操作对象。Queue是Topic的物理拆分，一个Topic包含多个Queue，分散在不同Broker上，实现水平扩展。生产者将消息分发到Queue，消费者绑定Queue消费，一个Queue仅对应一个集群消费者。Topic负责逻辑分类，Queue负责并发、存储、负载均衡，两者结合实现高吞吐、高可用的消息管理，是RocketMQ的基础架构模型。
RocketMQ通过集群化+主备+冗余实现高可用。NameServer集群部署，无单点故障；Broker多Master多Slave架构，主备数据同步，Master宕机Slave快速切换；主题多队列、多副本存储，单个节点故障不影响整体服务；消息持久化到磁盘，刷盘机制保证数据不丢；生产者、消费者自动路由到健康节点，故障自动转移。全链路冗余设计，配合自动故障切换、重试机制，保证消息服务7×24小时不间断，支撑大规模分布式业务。
RocketMQ支持主动拉取（Pull） 和推模式（Push） 两种，底层均基于Pull实现。Push模式是封装的便捷模式，消费者内部自动拉取，回调处理消息，开发简单；Pull模式是原生模式，手动调用拉取接口，自主控制消费节奏、批量大小，灵活性高。还支持长轮询拉取，优化实时性，减少无效请求。Push适合快速开发，Pull适合定制化消费、限流场景，两种模式按需选择，覆盖所有消费需求。
消费者先从NameServer拉取路由，绑定Broker队列，采用主动拉取+位点提交消费。集群模式下队列平均分配，广播模式全量接收；拉取消息后，串行/并行执行业务逻辑。消费成功手动提交位点，失败则触发重试。消费者定时发送心跳维持组内状态，队列变更时自动重平衡。消费过程支持并发控制、流量限制、异常捕获，全程自动化，开发只需关注业务逻辑，无需处理底层网络、路由细节，简单易用。
