Rocket MQ「1」简介

一.来历

    在早期,阿里巴巴基于Active MQ构建了分布式消息传输中间件。但随着贸易业务吞吐量的快速增长,中间件逐渐无法支持如此庞大的数据压力。尽管阿里巴巴采用节流、熔断器及服务降级等多种方案尝试解决,仍效果欠佳。

    阿里巴巴放弃了Active MQ并转而将目光投向了流行性消息传输解决方案Kafka,但遗憾的是Kafka也不能满足需求,尤其是在低延迟和高可靠性方面。

    在这种情况下,阿里巴巴决定发明一个新的消息传输引擎来处理更广泛的用例集(即现实中的各种情况),从传统的发布/订阅方案到大批量实时零损失容忍交易系统一概包含。Rocket MQ由此诞生,并被阿里巴巴贡献至Apache。

二.特性

  • 消息延迟性低:消费者以【长轮询】 +【 拉模型】方式消费消息。通过配置底层参数,可获得不亚于【推模型】的实时性;
  • 系统可用性高:分布式架构,支持集群;
  • 支持消息高堆积:10亿级的消息堆积可承受高强度的消息传输,并不会导致性能下降;
  • 消息可靠行性高:通过配置底层参数,可做到消息无丢失;
  • 保证数据一致性:使用事务性型消息可保证生产者与消费者之间数据的一致性。

三.适用场景

【附】参考文件1:首页 > 消息队列RocketMQ版 > 产品简介 > 适用场景

1.MQ适用场景(适用MQ的场景)
  • 异步解耦

    以注册后发送邮件及短信为例。

串行处理(150ms)
并行处理(100ms)
Rocket MQ处理(55ms)

    【注】Rocket MQ作为中间件承担了注册系统联系邮件系统及短信系统的工作。注册系统与另二者不再有直接关联 —— 解耦;
    【注】注册系统发送消息至Rocket MQ,邮件系统及短信系统自Rocket MQ中消费消息,二者互不影响并发执行 —— 异步。

  • 发布/订阅

    以注册后发送邮件及短信为例。

    上图中,注册系统在完成注册后,需分别请求邮件系统及短信系统。如后续接入其它系统,还需持续维护代码,逻辑如下:

    // 注册。
    register();
    // 发送邮件。
    sendEmail();
    // 发送短信。
    sendMessage();
    // 发送通知等(后续接入)。
    sendNotify();
    ......

    发布/订阅能很好的解决该问题。Rocket MQ支持发布/订阅模式(在Rocket MQ中被成为主题消费模式),它允许一条消息被多次消费。这代表注册系统只需向Rocket MQ发送一条消息,就可以被所有系统消费,包括后续接入的系统,因此也无需维护代码。

    // 注册。
    register();
    // 发送Rocket MQ消息。
    sendRocketMQMessage();
  • 削峰填谷

以秒杀后发送通知为例。

    在秒杀活动中,为了应对用户量的激增会为秒杀系统分配大量服务器资源以处理请求。但对于非即时系统通知系统而言,分配同等数量服务器资源显然是不明智的,但不分配则会导致通知系统瘫痪而漏发通知。

    Rocket MQ可以缓和这一过程。Rocket MQ会接收并保存秒杀系统发送的消息,而通知系统则会在能力范围内(这就使得系统不会崩溃)尽可能多的消费消息,直至将所有消息消费完毕。

2.Rocket MQ适用场景(最适用Rocket MQ的场景)

    因为阿里巴巴所涉业务要求极高的数据安全性,因此Rocket MQ设计初便将数据安全行视作重中之重。

  • 不允许消息丢失

    Rocket MQ有着完善的消息重试机制,通过对参数的配置、调整,可以做到消息无丢失。

  • 分布式事务的数据一致性

    以注册后发送邮件为例。

普通消息处理

    上述流程中,注册系统保存注册信息后,如果发送消息至Rocket MQ的过程失败,会导致注册系统与邮件系统的不一致。此时虽然可以通过将注册与发送消息的代码同时置于事务中并以主动/被动的方式抛出异常使其回滚,但将发送消息这类非数据库操作置于事务中的操作是极其不规范的。

    可以使用RocketMQ提供的事务消息来实现系统间的数据一致性。

事务消息处理
  • STEP 1 注册系统向RocketMQ发送半事务消息
         - STEP 1.1 半事务消息发送成功 ==》 STEP 2
         - STEP 1.2 半事务消息发送失败 ==》 OVER
  • STEP 2 注册系统开始注册
         - STEP 1.1 注册成功 ==》 STEP 3.1
         - STEP 1.2 注册失败 ==》 STEP 3.2
  • STEP 3 注册系统向RocketMQ发送半消息状态
         - STEP 3.1 提交半事务消息,产生注册成功消息 ==》 STEP 4
         - STEP 3.2 回滚半事务消息,未产生注册成功消息 ==》OVER
  • STEP 4 邮件通知系统接收RocketMQ的注册成功消息 ==》 STEP 5
  • STEP 5 邮件通知系统发送注册成功邮件 ==》 OVER

【下一篇】《Rocket MQ「2」架构》

### RabbitMQRocketMQ 的功能对比及适用场景 #### 功能对比 RabbitMQ 是一种基于 AMQP 协议的消息中间件,具有丰富的消息路由能力以及对多种协议的支持。其核心优势在于灵活性和多协议兼容性[^1]。相比之下,RocketMQ 则专注于高性能、高吞吐量的需求,在大规模分布式环境中表现出色。以下是两者的主要功能差异: - **消息协议支持** - RabbitMQ 支持多种消息协议(如 AMQP、STOMP、MQTT 等),这使得它能够适应更广泛的客户端环境和应用场景。 - RocketMQ 主要针对内部自定义协议优化,虽然也提供了 REST 接口扩展,但在跨协议适配方面不如 RabbitMQ 多样化。 - **性能表现** - RabbitMQ 在低延迟的小规模应用中有较好的表现,但由于其实现机制的原因,在极高并发下可能面临性能瓶颈。 - RocketMQ 经过阿里巴巴多年双十一活动验证,具备极高的吞吐能力和稳定性,特别适合处理海量数据流的任务。 - **持久性和可靠性** - RabbitMQ 提供了灵活的持久化选项,并且可以通过镜像队列实现高可用配置。 - RocketMQ 同样强调消息的可靠传递,采用主从同步复制技术保障数据安全,同时支持事务消息以满足强一致性要求。 - **管理工具** - RabbitMQ 自带一个易于使用的 Web UI —— Management Plugin ,方便用户查看节点状态、队列详情等信息。 - 对于 RocketMQ 而言,则有专门开发的 RocketMQ Console 工具,除了基础运维操作外还增加了更多高级特性比如流量分析图表展示等功能[^3]。 #### 适用场景 根据上述特点可以得出如下结论关于两者的最佳实践领域: - **RabbitMQ 更加契合以下情况:** - 需求涉及复杂的交换器模式或者定制化的消费逻辑; - 应用程序需要对接不同类型的通信标准 (例如 IoT 设备常用 MQTT ) ; - 小型项目或团队希望快速搭建起稳定可靠的异步通讯框架而无需过多关注底层细节 . - **RocketMQ 更倾向于应用于这些场合:** - 实时日志采集平台构建; - 广告投放系统中的点击事件追踪记录存储; - 社交网络好友动态推送服务架构设计等等一切追求极致效率的大数据相关业务环节 . ```python # 示例代码片段展示了如何创建简单的生产者/消费者模型(伪代码形式) from rocketmq.client import Producer, Message producer = Producer('group_name') producer.set_namesrv_addr('localhost:9876') msg = Message('TestTopic', body=b'Hello World!') result = producer.send_sync(msg) print(f'Send Result Status:{result.status}') ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

说淑人

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值