RocketMQ

RocketMQ

通用API
【更新时间: 2024.03.29】 RocketMQ 是由阿里慷慨捐赠给 Apache 的重要成果,它作为一款极为出色的分布式消息中间件,具有低延迟、高并发、高可用以及高可靠等显著特性,能够在各种复杂场景中稳定高效地实现消息传递与处理等相关服务。
服务星级:6星
⭐ ⭐ ⭐ ⭐ ⭐ ⭐ 🌟
浏览次数
11
采购人数
0
试用次数
0
! 适用于个人&企业
收藏
×
完成
取消
×
书签名称
确定
<
产品介绍
>

什么是RocketMQ?

"RocketMQ" 是一款高性能、高吞吐量的分布式消息中间件,由阿里巴巴开源并捐赠给 Apache 软件基金会,成为 Apache RocketMQ 项目。它旨在处理大规模的消息传递需求,广泛应用于互联网、金融、电信、物流等行业的核心业务系统中。

消息队列 RocketMQ版 是基于 Apache RocketMQ 构建的商业级消息中间件服务,通常由云服务提供商(如阿里云、腾讯云等)提供。这种服务形式不仅继承了 Apache RocketMQ 的所有核心功能和优势,还通过云服务的方式,为用户提供了更加便捷、灵活、可扩展的部署和管理方案。

什么是RocketMQ?

由服务使用方的应用程序发起,以Restful风格为主、通过公网HTTP协议调用RocketMQ,从而实现程序的自动化交互,提高服务效率。

RocketMQ有哪些核心功能?

消费模式多样

  1. 发布/订阅模式:这是消息队列最常见的消费模式。生产者(Producer)将消息发送到指定的主题(Topic),消费者(Consumer)订阅该主题并接收消息。RocketMQ确保每个消息只被每个消费者组(Consumer Group)中的一个消费者实例消费,即使存在多个消费者实例同时订阅同一主题。

  2. 集群消费模式:在集群消费模式下,多个消费者实例组成一个消费者组,共同消费同一个主题下的消息。RocketMQ通过负载均衡机制将消息均匀分配给组内的消费者实例,以提高消费能力和容错性。

  3. 广播消费模式:与集群消费模式不同,广播消费模式下,消息会被发送到订阅了该主题的每个消费者实例,而不管这些消费者实例是否属于同一个消费者组。这种模式适用于需要将消息广播给所有订阅者的场景。

消息类型丰富

  1. 普通消息:最基本的消息类型,支持同步、异步和单向发送方式。

  2. 顺序消息:保证消息的顺序性,适用于需要按特定顺序处理消息的场景,如订单处理、日志收集等。

  3. 事务消息:支持分布式事务的最终一致性。生产者先发送半事务消息到RocketMQ,然后执行本地事务。根据本地事务的执行结果,生产者向RocketMQ发送提交或回滚请求。RocketMQ根据这些请求来处理半事务消息,确保事务的最终一致性。

  4. 定时消息延时消息:允许生产者指定消息在特定时间后或延迟一段时间后才被消费。这适用于需要按时间顺序处理消息的场景,如定时任务、预约提醒等。                                                                                                                  

监控告警

  1. 消息查询和回溯:支持按时间、消息ID等条件查询消息,方便用户回溯消息处理过程。

  2. 消息重试与死信管理:对于消费失败的消息,RocketMQ支持自动重试机制。如果多次重试后仍无法消费成功,则可以将消息发送到死信队列中,供后续处理。

  3. 数据监控与告警:支持对消息堆积、消费延时等关键指标进行实时监控,一旦达到预设的阈值,系统将自动触发告警通知相关人员。

数据安全

  1. ACL访问策略:支持配置ACL(Access Control List)访问策略,通过密钥管理实现数据面的鉴权和授权。这有助于防止未经授权的访问和数据泄露。

  2. 密钥管理:提供密钥管理服务,用于生成、存储和管理访问密钥。这些密钥用于加密和解密消息内容或认证消息发送者和接收者的身份。

  3. 私有网络(VPC):支持将RocketMQ部署在私有网络中,通过VPC加强网络访问控制。这有助于隔离外部网络流量和保护内部数据资源的安全。

RocketMQ的技术原理是什么?

  1. 角色组成
    • NameServer:一个几乎无状态的节点,可集群部署,节点之间无任何信息同步。主要用来管理Broker的地址信息,为Producer和Consumer提供路由查询服务。
    • Broker:RocketMQ的核心组成部分,负责消息的存储和转发。Broker支持消息Push和Pull模式,支持千亿级别的消息堆积能力。
    • Producer:消息生产者,和NameServer通信获取topic路由信息,和NameServer保持长连接以及和该生产者关联的所有broker保持长连接。
    • Consumer:消费者,单个消费者和一台NameServer保持长连接,定时查询topic配置信息,根据topic路由和Broker保持长连接。
  2. 消息流程
    • 消息发布:Producer首先向NameServer查询目标Topic所在的Broker地址,然后将消息发送到这个Broker。
    • 消息存储:Broker接收到消息后,将消息存储在磁盘或内存中。为了提高效率,Broker会批量将消息存储到磁盘。
    • 消息订阅:Consumer启动时,向NameServer查询并订阅其感兴趣的Topic,NameServer返回对应的Broker地址。然后,Consumer直接和Broker建立连接,进行消息拉取或等待Broker推送消息。
    • 主从同步:为了保证数据的可靠性和高可用性,Broker可以配置为主从模式。在此模式下,主Broker负责处理读写请求,同时将数据同步到从Broker,以保证在主Broker宕机时,从Broker可以接管服务。
  3. 负载均衡
    • RocketMQ支持集群模式,可以通过增加Broker实例来水平扩展系统的处理能力。同时,它在Producer和Consumer端都实现了负载均衡,确保消息的均匀分布和消费。
  4. 消息确认与重试机制
    • 消费者处理消息后,需要向Broker发送确认信息。如果Broker在规定时间内没有收到确认,它会重新投递该消息。
    • 当消息消费失败时,RocketMQ支持自动重试,增强了消息处理的可靠性。

RocketMQ的核心优势是什么?

标准API接口
我们提供标准的API接口和详细的接入文档,帮助用户快速、便捷地将服务集成到自己的应用程序中。接入流程简单明了,无需复杂的配置和调试即可实现快速接入。

服务商账号统一管理
用户在幂简平台根据已使用的API服务采购API服务商的账号后,并在幂简平台进行创建、绑定、解绑等操作。通过采集分离的工具,使用账号资源进行产品运营

零代码集成服务商
通过一套改进过的流程来实现研发过程的零采购、零干扰。让程序员优先对接API服务,匹配业务需求,验证项目可行性上线之后再启动采购,24小时内即可上线运行

智能路由
采用智能路由规则,动态分配识别通道,有效提升了验证的准确率,其性能高于同行业平台,通过不断优化算法和模型,确保精准度和准确性

 

服务扩展

服务扩展不仅提供特性配置和归属地查询等增值服务,还能根据用户需求灵活定制解决方案,满足多样化的业务场景,进一步提升用户体验和满意度。

 

可视化监控
专注于性能和安全,通过监控调用量、成功率、响应时间和状态码来优化请求效率。安全机制利用网关和策略严格控制访问,防止违规调用。异常监控快速识别服务中断,确保稳定性和可靠性

在哪些场景会用到RocketMQ?

1. 异步解耦

在复杂的企业级应用架构中,"RocketMQ"的API接口被广泛应用于实现高效的异步通信机制,从而有效地解除多个业务系统之间的紧密耦合。这种解耦不仅提升了系统的灵活性和可扩展性,还保证了整体业务的连续性和稳定性。具体场景包括但不限于:

  • 微服务架构中的服务间通信:在微服务架构中,服务间的调用往往涉及复杂的依赖关系。通过RocketMQ,服务间的调用可以转变为异步消息传递,服务生产者发送消息后无需等待响应即可继续处理其他任务,而服务消费者则可以根据自身处理能力异步接收并处理消息。这种方式显著降低了服务间的耦合度,提高了系统的响应速度和吞吐量。

  • 订单处理与支付确认:在电商系统中,订单生成后通常需要调用支付服务进行支付确认。如果采用同步调用方式,订单服务将等待支付服务响应后才能继续后续流程,这可能导致系统性能瓶颈。通过RocketMQ,订单服务可以将支付请求作为消息发送到队列中,由支付服务异步处理并返回结果。这样,订单服务可以立即返回给用户订单已提交的响应,而无需等待支付服务的实际处理结果。

2. 削峰填谷

面对高并发、高流量的业务场景,"RocketMQ"的API接口作为流量缓冲器,发挥着至关重要的作用。它能够有效地收集上游系统的突增请求,并按照下游系统的实际消费能力平滑处理消息,从而避免系统过载和崩溃。具体场景包括:

  • 大促活动期间的流量控制:在电商大促期间,用户访问量和订单量会急剧增加,给系统带来巨大压力。通过RocketMQ,可以将用户请求和订单信息异步发送到消息队列中,由后端服务按需消费处理。这样,即使上游系统面临巨大的流量冲击,下游系统也能保持稳定的处理能力,确保业务平稳运行。

  • 数据同步与批量处理:在数据密集型应用中,如日志收集、用户行为分析等场景,系统需要实时或定期地将大量数据从一个系统同步到另一个系统。通过RocketMQ,可以将数据同步请求作为消息发送到队列中,由专门的消费者服务进行批量处理和同步。这种方式不仅可以降低系统间的耦合度,还可以提高数据同步的效率和可靠性。

3. 顺序收发

在某些业务场景中,消息的顺序性至关重要,如订单处理、金融交易等。"RocketMQ"提供了顺序消息的机制,确保消息的先进先出(FIFO)顺序,并支持全局和分区顺序消费,满足不同场景下的需求。

  • 订单处理流程:在电商系统中,订单的处理通常涉及多个步骤,如支付确认、库存扣减、物流分配等。这些步骤需要按照严格的顺序进行,以确保订单的正确性和一致性。通过RocketMQ的顺序消息功能,可以确保订单相关的消息按照生成顺序被消费处理,从而避免订单处理过程中的混乱和错误。

  • 金融交易记录:在金融系统中,交易记录的生成和处理也需要保持严格的顺序性。通过RocketMQ的分区顺序消费功能,可以将同一交易类型的消息发送到同一个分区中,确保这些消息被顺序消费处理。同时,分区顺序消费还支持动态扩展功能,可以根据业务量的增长灵活调整分区数量,提高系统的可扩展性和处理能力。

4. 消息追踪与审计

在需要高度监管和合规性要求的行业中,如金融、医疗等,消息的追踪与审计是不可或缺的一部分。这些行业往往需要对数据的完整性、准确性和安全性进行严格的监控和记录,以确保业务操作符合法规要求,同时预防潜在的风险和漏洞。"RocketMQ"的API接口在此类场景中发挥了重要作用,它不仅支持高效的消息传递,还提供了强大的消息追踪和审计功能。

  • 订消息追踪:在金融交易中,每一笔交易都伴随着多条消息的产生和处理。为了确保交易的透明度和可追溯性,需要对这些消息进行详细的追踪。RocketMQ通过其监控中心和API接口,提供了消息轨迹的查询功能,可以实时查看消息的发送时间、发送者、接收者、接收时间以及处理结果等关键信息。这有助于快速定位问题、排查故障,并在必要时进行审计和调查。

  • 审计日志:在医疗系统中,患者的健康数据和医疗记录是极其敏感和重要的。为了确保数据的合规性和安全性,医疗机构需要对所有涉及患者数据的操作进行详细的审计和记录。RocketMQ的日志系统可以与现有的审计系统集成,自动记录每一条消息的发送、接收和处理过程,包括消息的内容、时间戳、操作员等信息。这些审计日志可以作为法律证据,用于证明医疗操作的合规性和正确性,同时也为后续的故障排查和改进提供了宝贵的参考。

<
产品问答
>
?
角色组成: NameServer:一个几乎无状态的节点,可集群部署,节点之间无任何信息同步。主要用来...
消费组必须保证消费关系和逻辑完全一致。业务服务集群更新时,订阅关系可能会出现不一致,这时候只有交集是可靠消费,差集是不可靠消费。需要快速修正订阅关系,确保所有节点订阅的Topic一致。
?
同一个消息会被消费多次吗?
RocketMQ已经做到了同一个consumer group只会消费一次,但如果有业务消费幂等的需求(如生产中存在灰度服,服务版本大于正式服),仍然需要在消费逻辑中增加幂等处理。
?
持续生产的消息,在没有消费组的情况下会积压吗?
会积压。一直没有消费组的话,消息会按照一定策略(如48小时后)被清理。如果消息很重要,需要增加消费组的节点来增加消费速度,或者重置commitlog的offset。
?
消费组和Topic需要提前创建吗?
一般情况下,建议消费组和Topic提前创建好。但RocketMQ也支持动态创建Topic和消费组,不过需要注意相关的配置和可能的警告信息。
?
Broker的部署模式有哪些?
单Master模式:这是最简单的部署方式,但风险较大。只有一个Master节点,没有Slave节点,一旦Master节点重启或宕机,服务将不可用。这种模式一般用于测试环境,不建议在生产环境使用。 多Master模式:集群中全部为Master节点,没有Slave节点。优点是配置简单,单个Master节点宕机对应用影响较小,且性能较高。但缺点是当单个Master节点宕机时,该节点上未被消费的消息在节点恢复之前不可订阅,会影响消息的实时性。 多Master多Slave模式(异步复制):每个Master节点配置一个或多个Slave节点,HA(高可用)采用异步复制方式。这种方式下,消息写入Master后即返回成功ACK,然后主备之间异步同步消息。优点是即使磁盘损坏,消息丢失的很少,且Master宕机后消费者仍可从Slave消费,对应用透明。但缺点是主备之间有短暂的消息延迟,且Master宕机、磁盘损坏情况下会丢失少量消息。 多Master多Slave模式(同步双写):与异步复制模式类似,但主备之间采用同步双写方式,即只有主备都写成功才向应用返回成功。这种方式下,数据与服务都无单点故障,Master宕机情况下消息无延迟,服务可用性与数据可用性都非常高。但缺点是性能比异步复制模式略低,发送单个消息的RT会略高。
<
最可能同场景使用的其他API
>
API接口列表
<
依赖服务
>
<
产品问答
>
?
角色组成: NameServer:一个几乎无状态的节点,可集群部署,节点之间无任何信息同步。主要用来...
消费组必须保证消费关系和逻辑完全一致。业务服务集群更新时,订阅关系可能会出现不一致,这时候只有交集是可靠消费,差集是不可靠消费。需要快速修正订阅关系,确保所有节点订阅的Topic一致。
?
同一个消息会被消费多次吗?
RocketMQ已经做到了同一个consumer group只会消费一次,但如果有业务消费幂等的需求(如生产中存在灰度服,服务版本大于正式服),仍然需要在消费逻辑中增加幂等处理。
?
持续生产的消息,在没有消费组的情况下会积压吗?
会积压。一直没有消费组的话,消息会按照一定策略(如48小时后)被清理。如果消息很重要,需要增加消费组的节点来增加消费速度,或者重置commitlog的offset。
?
消费组和Topic需要提前创建吗?
一般情况下,建议消费组和Topic提前创建好。但RocketMQ也支持动态创建Topic和消费组,不过需要注意相关的配置和可能的警告信息。
?
Broker的部署模式有哪些?
单Master模式:这是最简单的部署方式,但风险较大。只有一个Master节点,没有Slave节点,一旦Master节点重启或宕机,服务将不可用。这种模式一般用于测试环境,不建议在生产环境使用。 多Master模式:集群中全部为Master节点,没有Slave节点。优点是配置简单,单个Master节点宕机对应用影响较小,且性能较高。但缺点是当单个Master节点宕机时,该节点上未被消费的消息在节点恢复之前不可订阅,会影响消息的实时性。 多Master多Slave模式(异步复制):每个Master节点配置一个或多个Slave节点,HA(高可用)采用异步复制方式。这种方式下,消息写入Master后即返回成功ACK,然后主备之间异步同步消息。优点是即使磁盘损坏,消息丢失的很少,且Master宕机后消费者仍可从Slave消费,对应用透明。但缺点是主备之间有短暂的消息延迟,且Master宕机、磁盘损坏情况下会丢失少量消息。 多Master多Slave模式(同步双写):与异步复制模式类似,但主备之间采用同步双写方式,即只有主备都写成功才向应用返回成功。这种方式下,数据与服务都无单点故障,Master宕机情况下消息无延迟,服务可用性与数据可用性都非常高。但缺点是性能比异步复制模式略低,发送单个消息的RT会略高。
<
最可能同场景使用的其他API
>