消息队列 MQ

阿里云消息队列(Message Queue,简称 MQ)是由阿里巴巴自研的分布式消息队列服务,由阿里云平台完全托管,能够在微服务、分布式系统和无服务应用程序之间,提供基于消息的可靠异步通信机制,轻松构建松耦合、可扩展、高可用分布式系统。

立即购买 联系销售

阿里云消息队列

阿里云消息队列(Message Queue,简称 MQ)是由阿里巴巴自研的分布式消息队列服务,由阿里云平台完全托管,能够在微服务、分布式系统和无服务应用程序之间,提供基于消息的可靠异步通信机制,轻松构建松耦合、可扩展、高可用分布式系统。

MQ 服务于阿里巴巴集团超过 11 年,历经天猫双十一活动 9 年,具备低延迟、高并发、高可用、高可靠、可支撑万亿级数据洪峰和超强消息堆积能力,借助 MQ,您可以在任意规模的应用组件之间自由地传递数据。

2017 年 9 月,消息队列内核引擎 RocketMQ 成为 Apache 的顶级项目,秉持开放、共享、共建的原则,拥抱开源生态,无技术绑定。基于 OpenMessaging 下一代消息引擎架构,面向 4 大领域,支撑混合云多语言架构,已在 linux foundation 完成落地,有望成为分布式消息领域的国际标准。


优点

高性能 & 低延迟

  • 高性能
    支持千万级的 QPS(每秒钟消息收发条数),万亿级的消息流转,无并发限制,无性能上限;

  • 海量堆积
    在海量消息堆积的情况下,始终保持高性能,不影响集群的正常服务,在削峰填谷(蓄洪)的场景下,显得尤其重要;

  • 低延迟
    经过历年双十一反复打磨,攻克了在超高并发情况下因系统负载过高导致的慢请求响应时间抖动问题,在 2017 年双十一万亿消息流转中 99.6% 的消息写入延迟在 1ms 以内,99.996% 的消息写入延迟在 10ms 以内;

  • 实时推送
    消息到达服务器立刻投递,保证消息实时性;

高可用 & 高可靠 & 可扩展

  • 服务高可用
    MQ 作为阿里云正式商用的产品,已在全球多个地域提供了高可用消息云服务,机房硬件设施按照阿里巴巴自建 IDC 的高标准实施。每个 Region 均采用多机房部署,即便整个机房都不可用,仍可以为应用提供消息的发布服务。

  • 数据高可靠
    同步双写、跨机房超三副本数据冗余以及数据副本的快速切换技术,保证数据可靠性高达 99.99999999%;

  • 可扩展
    支持万级 Topic,队列数可弹性扩展;集群规模可自动扩缩,对用户完全透明;

  • 同城多活
    在中国华东 1、中国华东 2、中国华南 1 等多个金融专区,提供同城多活的部署方案,为金融核心交易系统保驾护航。

安全访问控制

  • 权限控制
    以消息主题(Topic)、订阅组(ConsumerId)的粒度对用户访问权限进行控制,对每一条消息(Message)的收、发都进行严格的访问控制,确保消息的安全性;

  • 主子账号
    全面支持阿里云 RAM 主子账号、黑白名单、STS 等功能;

  • 授权
    支持跨账号授权与主子账号授权;

  • 安全
    支持 TLS 传输加密协议、阿里云 VPC 访问等;


主题模型(Topic)

  • Pub/Sub 模式
    MQ 支持 Pub/Sub 模式,Producer 将消息发往指定 Topic,可被一个或者多个 Consumer 进行订阅;

  • 消费模型
    支持集群消费与广播消费,并约定使用相同 Consumer ID 的订阅者属于同一个集群;集群消费模式下,每条消息只需要被集群内的任意一个订阅者处理;广播消费模式下,每条消息将推送给集群内所有订阅者,保证消息至少被集群内的每个订阅者消费一次;


丰富的消息类型

  • 普通消息
    普通的消息类型,解决系统间异步解耦,削峰填谷,日志服务,大规模机器的Cache同步,实时计算分析等;

  • 顺序消息
    按照消息的发布顺序进行顺序消费(FIFO),支持全局顺序与分区顺序;

  • 事务消息
    MQ 提供类似 X/Open XA 的分布事务功能,通过 MQ 事务消息能达到分布式事务的最终一致;

  • 定时消息
    将消息发送到 MQ 服务端,在消息发送时间(当前时间)之后的指定时间点进行投递,比如指定时间在 2016/01/01 15:00:00 进行消息投递;

  • 延时消息
    将消息发送到 MQ 服务端,在消息发送时间(当前时间)之后的指定延迟时间点进行投递,比如指定消息发送时间的 30 分钟之后进行投递;


体系化运维配套

  • 消息查询
    用户可以通过 Topic/Message ID/Message Key 查询 MQ 服务器上的消息;

  • 全链路消息轨迹
    完整记录消息在消息的生产方、消息队列服务器、消息的消费方之间流动的全过程数据,并将这些数据汇聚分析,构成可视化的全链路消息轨迹;

  • 消息回溯
    通过指定时间的方式,对已经消费过的消息进行回放,是帮助用户进行故障处理的一柄利器;

  • 资源报表
    通过可以查看每个消息主题(Topic)、订阅组(ConsumerId)的历史数据与实时数据,帮助用户进行数据分析;

  • 监控告警
    每个订阅组都可以根据消息的消费延时间、消息堆积量等因素进行监控告警设置,帮助用户及时发现问题;

  • Open API(RESTful)
    MQ 提供给用户的一整套完备的管控类 Open API,用于实现一系列资源管理和运维功能,采用 HTTP RESTful 标准,接入方便;


计费模型

  • 预付费(包年包月),主要提供 MQ 企业铂金版,售卖规格请情可前往MQ 铂金版查看

  • 后付费(按量付费),具体信息参考下文说明。

按量付费计费项目

  • MQ 费用 = API 调用费 + Topic 资源占用费

  • API 调用次数 = 发送消息 API 调用次数 + 订阅消息 API 调用次数 + 长轮询 API 调用次数
    长轮询说明:MQ Consumer 为保证消息实时推送而产生的 API 调用,每个队列 15 秒一次长轮询,在此期间,若队列内有消息产生,则不计长轮询次数。


按量付费价格详情

API 调用费(单位:美元/百万次)

按阶梯计费调用次数/月累计中国香港
新加坡
马来西亚
第一阶梯0~10亿次0.450.42
第二阶梯10亿次~50亿次0.410.38
第三阶梯50亿次~100亿次0.340.31
第四阶梯100亿次~500亿次0.30.27
第五阶梯500亿次以上0.270.25



Topic 资源占用费(单位:美元/Topic)

按阶梯计费调用次数/日/Topic中国香港
新加坡
马来西亚
第一阶梯0~10亿次0.450.42
第一阶梯100亿次~500亿次0.340.31
第二阶梯500亿次~1000亿次0.110.11
第四阶梯1000亿次以上00

计费说明

1. MQ 后付费产品,每小时进行一次结算,每 24 小时出一次账单(次日出账单),费用将自动从账户余额中扣除;
2. Topic 资源占用费按每个 Topic 每日 API 调用次数阶梯计费,主-主账号授权双方均正常计费,主-子账号授权所有计费归属主账号;不再使用的 Topic 请及时删除,避免产生不必要的费用;
3. 调用发送接收 API 均计费,计量单位为百万次;API 调用次数包括长轮询 API 的调用,正常收发消息时,不会产生多余长轮询 API 调用;
4. 消息体大小最大限制为 4 MB,每 4 KB 发布或订阅数据以 1 次请求计费。例如,1 次负载(发布或订阅)为 256 KB 的 API 调用将以 256/4 次请求计费;
5. 事务消息发布请求 1 次按照 50 次计费,订阅按照普通消息计费。例如,发布事务消息 1 次,订阅该消息 1 次,按照 50+1=51 次 API 调用计费;
6. 顺序消息发布请求 1 次按照 25 次计费,订阅请求 1 次按照 25 次计费。例如,发布顺序消息 1 次,订阅该消息 1 次,按照 25+25=50 次 API 调用计费;
7. 定时消息发布请求一次按照 25 次计费,订阅按照普通消息计费。例如,发布定时消息 1 次,订阅该消息1 次,按照 25+1=26 次 API 调用计费;
8. 金融云 Region 计费系数为公共云 Region 的 1.9 倍。


免费说明

1. 每月前 2000 万次 API 调用免费,所有 Region 累计计算。


欠费说明

1. MQ 服务费用的计费周期为 24 小时,即阿里云将在下一个自然日就您上一个自然日的服务使用进行计量、出具账单并自您的阿里云账户中按账单金额扣划服务费用。账单出账时间通常在当前计费周期结束后 8 至 10 个小时内。
2. 当前您的账户余额不足以支付账单金额,MQ 处于欠费状态超过 72 小时,阿里云将暂停为您提供服务,释放 MQ 服务,即您不能再访问 MQ 控制台与 MQ API 。未处理的消息数据将自动释放,被释放的数据不可恢复。
3. 预付费实例(MQ 企业铂金版、LMQ 微消息队列),实例到期后,阿里云将暂停为您提供服务,168 小时内仍未续费,实例将自动释放,被释放实例与数据均不可恢复。


场景

MQ 广泛应用于电子商务,金融,大数据,物联网等领域。

解耦

系统间的松耦合,有助于提高可扩展性和可靠性,是适用于现代应用程序的最佳设计方案。
借助 MQ,您可以在任何数量的应用服务组件(系统)之间发送、存储和接收消息,保证不丢消息,从而使得云应用服务组件(系统)的工作得到简化,达到更高的成本效益。

削峰填谷(蓄洪)

诸如天猫双 11 凌点交易高峰、秒杀、春晚抢红包等大型活动时,当外部请求超过系统处理能力负荷时,将导致请求大量的失败;若系统没有做相应保护,可能由于历史累计的超时请求过多,因无法自动恢复而导致系统崩溃,对外呈现的服务能力为 0,极大影响用户的体验;

分布式事务

在传统的事务处理中,多个系统或者应用组件之间的业务处理会耦合到一个大事务中,响应时间长,业务链路长从而影响系统可用性。引入消息队列(MQ)的分布式事务消息后,可以将需要同步处理的核心链路业务与可异步化处理的分支链路业务进行拆分,从而将一个大事务拆分成一个小事务,进而减少系统间的交互。
通过 MQ 的分布式事务消息,既能保证分布式系统之间数据的最终一致,又能将业务系统(购物车、积分、其他)之间解耦,从而达到最佳的架构设计。

实时计算

数据在"流动"中产生价值,传统数据分析大多是基于批量计算模型,而无法做到实时的数据分析,利用阿里云消息队列(MQ)与流式计算引擎 (Spark/Storm/EMR/ARMS/BeamRunner等) 相结合,可以很方便的实现将业务数据进行实时分析。

大规模缓存同步

在大型活动中的分会场或者大规模的 App 客户端中,为降低请求的 RT 时间提高客户的体验,都会使用大规模缓存设计。如 “双11” 大促,各个分会场、如手淘 App、天猫 App 都会有琳琅满目的商品,每件商品的价格都会根据活动状态实时发生变化,大量并发访问商品数据库会场页面响应时间长,集中式缓存带宽成瓶颈,无法满足对商品价格的访问需求。针对分会场的多缓存设计,通过消息队列(MQ),可以实现多缓存间的同步,从而满足客户对商品价格的访问需求。

IM

在阿里巴巴,无论是交易中使用的旺旺或是企业移动办公平台钉钉,都是通过消息队列(MQ)中的消息完成每一次的沟通以及社交活动。无论是单聊、群聊、钉钉通知、抢红包,每次交互都会产生大量的消息。

使用入门

MQ 快速接入流程图:

1. 开通服务

公共云用户请按以下步骤开通 MQ 服务:

  • 登录阿里云主页(https://www.alibabacloud.com),将鼠标依次移动到产品 > 互联网中间件,单击消息队列进入 MQ 产品主页。

  • 单击立即开通进入 MQ 服务开通页面,根据提示完成开通服务。

如果您已经开通 MQ 服务,请直接登录MQ 控制台

2. 申请资源

在 MQ 消息系统中,消息发布者将消息发送到某个指定的消息主题(Topic) ,而消息订阅者则通过订阅该指定的 Topic 来获取和消费消息。

详情您可前往申请资源查看。

3. 发送消息

在控制台申请 Topic 资源后,您可以通过控制台发送消息或者调用 SDK/API 发送消息。控制台发送消息主要用于快速验证 Topic 资源的可用性,在生产环境下使用 MQ 建议调用相关的 SDK/API 进行消息发送。

详情您可前往发送消息查看。

4. 订阅消息

消息发送成功后,需要启动订阅方进行消息订阅。本文以 TCP Java SDK 为例,介绍如何通过调用相关协议及开发语言的 SDK/API 来完成消息订阅。

详情您可前往订阅消息查看。

MQ SDK 版本说明:

MQ 各种多语言版本 SDK 的下载以及 Release Note 可前往MQ SDK 版本说明查看。

资源

以下资源提供了消息队列MQ 的详情

开发资源​​​​​

常见问题

1. MQ 是否可以在公网访问?
支持,MQ 专门开辟了公网专用集群供测试使用。在 MQ 控制台创建 Topic 时,Region 请选择“公网”。此 Topic 即可通过公网访问,但可用性较低。
当正式投入生产时,务必使用可用性更高的生产环境 Region,部署在阿里云 ECS 上进行收发消息。

2. 新创建的 Consumer ID从哪里开始消费?
如果这个 Consumer ID 是第一次启动,则会忽略启动之前发送的消息,也就是忽略历史消息,从启动之后发送的消息开始消费。
如果这个 Consumer ID 是第二次启动,那么从上次消费的位置开始消费。
如果想从特定位置开始消费,可以通过 MQ 控制台的消费位点重置功能,指定到具体的时间开始消费。每次重置只针对特定 Consumer ID 下的特定 Topic,不会影响其他 Consumer ID。

3. MQ 消费失败如何重新消费消息?
消费业务逻辑代码如果返回 Action.ReconsumerLater,或者 NULL,或者抛出异常,消息都会走重试流程,至多重试 16 次,如果重试 16 次后,仍然失败,则消息丢弃。每次重试的间隔时间如下:

第几次重试每次重试间隔时间
110 秒
230 秒
31 分钟
42 分钟
53 分钟
64 分钟
75 分钟
86 分钟
97 分钟
108 分钟
119 分钟
1210 分钟
1320 分钟
151 小时
152 小时

可以通过调用 message.getReconsumeTimes() 方法来获取消息的重试次数。
广播消费方式:广播消费方式仍然能保证一条消息至少被消费一次,但消费失败后不做重试操作。

4. 消息发送了,但是没有收到怎么办?
MQ 提供了多种消息查询方式:
* 使用 Topic 按时间范围进行查询,可以查询到一段时间内某 Topic 收到的所有消息。
* 使用 Topic 和 Message ID 对消息进行精准查询。
* 使用 Topic 和 Message Key 较为精准地查询具有相同 Message Key 的一类消息。
上述方式可以查询到消息的具体内容以及消费情况,如果需要追踪一条消息从生产者发出到被消费者消费的整个链路中各个相关节点的时间地点,可以使用 MQ 最新的消息轨迹查询功能,具体使用方式请参考消息轨迹使用指南

5. MQ 是否能保证消息不重复?
绝大多数情况下,消息是不重复的。作为一款分布式消息中间件,在网络抖动、应用处理超时等异常情况下,无法保证消息不重复,但是能保证消息不丢失。