RocketMQ教程-简介

什么是云消息队列 RocketMQ 版？

云消息队列 RocketMQ 版是阿里云基于Apache RocketMQ构建的低延迟、高并发、高可用、高可靠的分布式“消息、事件、流”统一处理平台，面向互联网分布式应用场景提供微服务异步解耦、流式数据处理、事件驱动处理等核心能力。

为什么选择云消息队列 RocketMQ 版

云消息队列 RocketMQ 版基于阿里云云原生优质的基础设施实现，兼容Apache RocketMQ的核心API和功能。

相对于自建RocketMQ集群，云消息队列 RocketMQ 版具有如下优势：

应用场景

云消息队列 RocketMQ 版基于统一消息存储和轻量计算层，主要应用于微服务异步解耦、流式数据处理、事件驱动等场景。

业务消息-异步解耦、削峰填谷

云消息队列 RocketMQ 版初始于阿里巴巴双十一核心链路，广泛应用于物流、购物车、积分等微服务业务系统，有效承载系统间异步解耦和流量削峰填谷的作用。通过使用云消息队列 RocketMQ 版，可有效实现如下作用：

异步解耦缩短链路

通过云消息队列 RocketMQ 版将上游业务和下游系统进行解耦，缩短了无服务调用的链路。系统异步化后响应时间更短、上下游轻松耦合，开发效率更高。

削峰填谷提高稳定性

传统消息中间件仅满足业务的异步化需求，而云消息队列 RocketMQ 版诞生于在线互联网和交易业务场景，除了满足异步能力，还将削峰填谷作为消息的基础能力。通过削峰填谷不仅能够提高系统稳定性，还能大幅降低业务成本。

实现削峰填谷的功能，消息中间件需要支持海量的消息堆积能力以及处理好冷热消息混合情况下的流量模型。云消息队列 RocketMQ 版能够提供亿级消息堆积能力，可以在大促等流量峰值场景下抗住流量洪峰，保证下游业务能够在安全水位内平滑稳定的运行。

业务消息-异步解耦、分布式事务

云消息队列 RocketMQ 版分布式事务消息的方案具备如下优势：

• 系统性能高

  基于最终一致性的事务消息方案，相比传统XA事务，吞吐性能更高，可扩展性更强。

• 开发成本低

  基于事务消息开发逻辑简单，仅需两阶段接口即可完成多个事务分支的协调，无需业务做补偿处理。

下图以创建订单为例对比传统事务和云消息队列 RocketMQ 版事务消息的方案：

 业务消息-分布式定时/延时调度

云消息队列 RocketMQ 版提供精确度到秒级的分布式定时消息能力，可广泛应用于订单超时中心处理、分布式延时调度系统等场景。

使用云消息队列 RocketMQ 版定时消息有如下优势：

• 定时精度高、开发门槛低

  消息定时时间不存在阶梯间隔，可以轻松实现任意精度事件触发，无需业务去重。

• 高性能、可扩展

  传统的定时实现方案较为复杂，需要进行数据库扫描，容易遇到性能瓶颈的问题，云消息队列 RocketMQ 版可以基于定时消息特性完成事件驱动，实现百万级消息TPS能力。

流式处理

云消息队列 RocketMQ 版具备海量吞吐的流式存储能力，可以有效对接日志收集、数据集成和数据分析等系统。通过云消息队列 RocketMQ 版可以将上游数据分发到下游的实时计算、离线存储等系统。

事件驱动

云消息队列 RocketMQ 版可以结合事件总线EventBridge轻松实现事件驱动新模式，消息数据经过事件总线EventBridge的可视化事件规则，驱动下游函数计算、HTTP接口、第三方自定义等数据目标。

核心技术点

• Topic：消息主题，一级消息类型，生产者向其发送消息。

• Message：生产者向Topic发送并最终传送给消费者的数据消息的载体。

• 消息属性：生产者可以为消息定义的属性，包含Message Key和Tag。

• Message Key：消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。

• Message ID：消息的全局唯一标识，由消息队列RocketMQ系统自动生成，唯一标识某条消息。

• Tag：消息标签，二级消息类型，用来进一步区分某个Topic下的消息分类

• Producer：也称为消息发布者，负责生产并发送消息至Topic。

• Consumer：也称为消息订阅者，负责从Topic接收并消费消息。

• 分区：即Topic Partition，物理上的概念。每个Topic包含一个或多个分区。

• 消费位点：每个Topic会有多个分区，每个分区会统计当前消息的总条数，这个称为最大位点MaxOffset；分区的起始位置对应的位置叫做起始位点MinOffset。

• Group：一类生产者或消费者，这类生产者或消费者通常生产或消费同一类消息，且消息发布或订阅的逻辑一致。

• Group ID：Group的标识。

• 队列：个Topic下会由一到多个队列来存储消息。

• Exactly-Once投递语义：Exactly-Once投递语义是指发送到消息系统的消息只能被Consumer处理且仅处理一次，即使Producer重试消息发送导致某消息重复投递，该消息在Consumer也只被消费一次。

• 集群消费：一个Group ID所标识的所有Consumer平均分摊消费消息。例如某个Topic有9条消息，一个Group ID有3个Consumer实例，那么在集群消费模式下每个实例平均分摊，只消费其中的3条消息。

• 广播消费：一个Group ID所标识的所有Consumer都会各自消费某条消息一次。例如某个Topic有9条消息，一个Group ID有3个Consumer实例，那么在广播消费模式下每个实例都会各自消费9条消息。

• 定时消息：Producer将消息发送到消息队列RocketMQ服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到Consumer进行消费，该消息即定时消息。

• 延时消息：Producer将消息发送到消息队列RocketMQ服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到Consumer进行消费，该消息即延时消息。

• 事务消息：RocketMQ提供类似X/Open XA的分布事务功能，通过消息队列RocketMQ的事务消息能达到分布式事务的最终一致。

• 顺序消息：RocketMQ提供的一种按照顺序进行发布和消费的消息类型，分为全局顺序消息和分区顺序消息。

• 全局顺序消息：对于指定的一个Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。

• 分区顺序消息：对于指定的一个Topic，所有消息根据Sharding Key进行区块分区。同一个分区内的消息按照严格的FIFO顺序进行发布和消费。Sharding Key是顺序消息中用来区分不同分区的关键字段，和普通消息的Message Key是完全不同的概念。

• 消息堆积：Producer已经将消息发送到消息队列RocketMQ的服务端，但由于Consumer消费能力有限，未能在短时间内将所有消息正确消费掉，此时在消息队列RocketMQ的服务端保存着未被消费的消息，该状态即消息堆积。

• 消息过滤：Consumer可以根据消息标签（Tag）对消息进行过滤，确保Consumer最终只接收被过滤后的消息类型。消息过滤在消息队列RocketMQ的服务端完成。

• 消息轨迹：在一条消息从Producer发出到Consumer消费处理过程中，由各个相关节点的时间、地点等数据汇聚而成的完整链路信息。通过消息轨迹，您能清晰定位消息从Producer发出，经由消息队列RocketMQ服务端，投递给Consumer的完整链路，方便定位排查问题。

• 重置消费位点：以时间轴为坐标，在消息持久化存储的时间范围内（默认3天），重新设置Consumer对已订阅的Topic的消费进度，设置完成后Consumer将接收设定时间点之后由Producer发送到消息队列RocketMQ服务端的消息。

• 死信队列：死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列RocketMQ会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明Consumer在正常情况下无法正确地消费该消息。此时，消息队列RocketMQ不会立刻将消息丢弃，而是将这条消息发送到该Consumer对应的特殊队列中。  消息队列RocketMQ将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。

• Name Server：是一个几乎无状态节点，可集群部署，在消息队列RocketMQ版中提供命名服务，更新和发现Broker服务。

• Broker：消息中转角色，负责存储消息，转发消息。分为Master Broker和Slave Broker，一个Master Broker可以对应多个Slave Broker，但是一个Slave Broker只能对应一个Master Broker。Broker启动后需要完成一次将自己注册至Name Server的操作；随后每隔30s定期向Name Server上报Topic路由信息。

• 生产者：与Name Server集群中的其中一个节点（随机）建立长链接（Keep-alive），定期从Name Server读取Topic路由信息，并向提供Topic服务的Master Broker建立长链接，且定时向Master Broker发送心跳。

• 消费者：与Name Server集群中的其中一个节点（随机）建立长连接，定期从Name Server拉取Topic路由信息，并向提供Topic服务的Master Broker、Slave Broker建立长连接，且定时向Master Broker、Slave Broker发送心跳。Consumer既可以从Master Broker订阅消息，也可以从Slave Broker订阅消息，订阅规则由Broker配置决定。