一.来历
在早期,阿里巴巴基于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提供的事务消息来实现系统间的数据一致性。
事务消息处理
Step1:注册系统向RocketMQ发送半事务消息
Step1.1:半事务消息发送成功 ==》 Step2
Step1.2:半事务消息发送失败 ==》 Over
Step2:注册系统开始注册
Step2.1:注册成功 ==》 Step3.1
Step2.2:注册失败 ==》 Step3.2
Step3:注册系统向RocketMQ发送半消息状态
Step3.1:提交半事务消息,产生注册成功消息 ==》 Step4
Step3.2:回滚半事务消息,未产生注册成功消息 ==》 Over
Step4:邮件通知系统接收RocketMQ的注册成功消息 ==》 Step5
Step5:邮件通知系统发送注册成功邮件 ==》 Over