Rocket MQ 的前世与今生
RocketMQ是⼀款阿⾥巴巴开源的消息中间件,在2017年9⽉份成为Apache的顶级项⽬,是国内⾸个互联⽹中间件在 Apache 上的顶级项⽬。
RocketMQ经历了4个大阶段(如上图):
阶段1:Metaq(Metamorphosis) 1.x 由开源社区 killme2008 维护,最后⼀次更新是在2017年1⽉份。
阶段2:Metaq 2.x 于 2012 年 10 ⽉份上线,在淘宝内部被⼴泛使⽤。
阶段3:RocketMQ 3.x 基于阿⾥内部开源共建原则, RocketMQ 项⽬只维护核⼼功能,且去除了所有其他运⾏时依赖, 核⼼功能最简化。每个 BU 的个性化需求都在 RocketMQ 项⽬之上进⾏深度定制。 RocketMQ 向其他 BU 提供的仅仅是Jar 包,例如要定制⼀个 Broker,那么只需要依赖 rocketmq-broker 这个 jar 包即 可,可通过 API 迕⾏交互,如果定制 client,则依赖 rocketmq-client 这个 jar 包,对其提供的 api 进⾏ 再封装。
阶段4:进⼊Apache 2016年11⽉28⽇,阿⾥巴巴向 Apache 软件基⾦会捐赠消息中间件 RocketMQ,成为 Apache 孵 化项⽬。美国时间 2017 年 9 ⽉ 25 ⽇,Apache 软件基⾦会(ASF)宣布 Apache®RocketMQ™ 已孵化 成为 Apache 顶级项⽬(TLP ),是国内⾸个互联⽹中间件在 Apache 上的顶级项⽬。
各种MQ产品的比较
此处比较并没有列出ActivateMQ,因为ActivateMQ目前使用占额已经越老越小,所以此次 不再拿出来进行比较。
功能对比:
总结:
- Kafka:系统间的数据流通道
- RocketMQ:⾼性能可靠消息传输
- RabbitMQ:低延迟可靠性传输
使用场景
1.异步解耦
场景:用户注册后,需要发送注册邮件和短信通知,以告知用户注册成功;传统的做法有以下两种。
串行方式:
并行方式:
MQ解耦:
总结:从三种实现方式可以看出,使用MQ进行异步解耦能让服务的功能变得更单一、更高效,明确功能的主次。
2.削峰填谷
场景:在秒杀或团队抢购活动中,由于用户请求量较大,导致流量暴增,秒杀的应用在处理如此大量的访问流量后,下游的通知系统无法承载海量的调用量,甚至会导致系统崩溃等问题而发生漏通知的情况。
总结:在互联网开发过程中突发大流量情况非常多,也有很多成熟的解决方案,使用MQ来进行削峰填谷也是业界比较成熟的一个方案。
3.数据同步与check
场景:订单数据存储为分片数据库,不利于聚合查询和批量操作,利用binlog将数据同步到MQ中,业务消费MQ对数据加工处理,可以将数据同步到其它存储系统,也可以做数据Check等
总结:采用订阅Binlog方式,将数据打进MQ进行临时存储,其它服务可以通过订阅MQ进行处理自己的业务,比如数据同步、数据一致性检查待。
4.其它场景
当然MQ还有其它一些使用场景,在这里就不在一一介绍了,具体如下:
- 顺序收发
- 分布式事务⼀致性
- ⼤数据分析
- 分布式缓存同步
这些使用场景可以说是MQ的优点,但是同样也会带来一些问题:
使用MQ后的缺点:
1)系统更复杂,多了一个MQ组件
2)消息传递路径更长,延时会增加
3)消息可靠性和重复性互为矛盾,消息不丢不重难以同时保证
4)上游无法知道下游的执行结果,这一点是很致命的
<