RocketMQ

RocketMQ是阿里巴巴开源的分布式消息中间件，基于Java开发，专为高吞吐、高可靠的分布式系统设计。 核心特点 ①高吞吐量（支持千万级TPS）； ②低延迟（毫秒级响应）； ③支持多种消息模式（普通消息、顺序消息、事务消息等）； ④完善的重试和死信机制； ⑤分布式架构，支持水平扩展； ⑥提供丰富的监控和运维工具。 消息队列优势 系统解耦：解决不同重要程度、不同能力级别系统之间依赖导致一死全死；大多数MQ支撑多语言客户端，可兼容多语言发开发； 削峰填谷：主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题 异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 提升性能：当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统 蓄流压测：线上有些链路不好压测，可以通过堆积一定量消息再放开来压测 数据冗余：有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。MQ把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多MQ所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 核心组件 **生产者（Producer）：**Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调用链路的上游。生产者是轻量级匿名无身份的。 消息存储 主题（Topic）：Apache RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。 队列（MessageQueue）：Apache RocketMQ 消息传输和存储的实际单元容器，类比于其他消息队列中的分区。 Apache RocketMQ 通过流式特性的无限队列结构来存储消息，消息在队列内具备顺序性存储特征。 消息（Message）：Apache RocketMQ 的最小传输单元。消息具备不可变性，在初始化发送和完成存储后即不可变。 消息消费 消费者分组（ConsumerGroup）：Apache RocketMQ 发布订阅模型中定义的独立的消费身份分组，用于统一管理底层运行的多个消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展。 消费者（Consumer）：Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须被指定到某一个消费组中。 订阅关系（Subscription）： Apache RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。 Apache RocketMQ 的订阅关系除过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留。 Broker：消息服务器，存储消息并处理收发请求，由多个节点组成集群，分为Master和Slave（Master负责读写，Slave同步数据并提供读服务）。 NameServer：轻量级注册中心，存储Broker的路由信息（如Topic与Broker的映射关系），支持动态扩容，无状态且节点间互不通信。 NameServer是RocketMQ的“路由中枢”，核心作用是存储和更新集群的路由信息，为生产者和消费者提供Broker的地址发现服务。 与Broker的交互机制： ①Broker启动时向所有NameServer注册自身信息（如IP、端口、Topic配置等）； ②Broker定期（默认30秒）向NameServer发送心跳包，维持在线状态； ③NameServer在120秒内未收到Broker心跳，则将其从路由信息中移除，保证路由的实时性。 保证消息的可靠性 RocketMQ的消息可靠性保证贯穿于消息生产、Broker存储、消息消费全链路，通过多层次机制确保消息不丢失、不重复，具体如下： 一、生产端：确保消息成功发送到Broker 生产者（Producer）发送消息时，通过“重试机制+确认机制”避免因网络波动、Broker临时故障导致的消息丢失。 发送确认机制 RocketMQ支持三种发送方式，均通过Broker的响应确认消息是否成功送达： 同步发送：Producer发送消息后，等待Broker返回“发送成功”确认（包含消息ID和存储位置），才视为发送完成；若超时未收到确认，触发重试。 异步发送：Producer发送消息后立即返回，通过回调函数接收Broker的确认结果；若失败，在回调中处理重试。 单向发送：仅发送消息不等待确认（适用于日志等非核心场景），但核心业务一般不使用，避免丢失。 失败重试机制 当发送失败（如网络超时、Broker繁忙）时，Producer会自动重试，可通过参数配置： retryTimesWhenSendFailed：同步发送失败重试次数（默认2次）。 retryTimesWhenSendAsyncFailed：异步发送失败重试次数（默认2次）。 重试时会选择其他Broker节点（通过NameServer获取路由信息），避免单节点故障影响。 二、Broker端：确保消息持久化与集群可靠性 Broker作为消息存储核心，通过“持久化存储+主从复制+故障转移”保证消息不丢失。 ...