先说一下本人使用RocketMQ的背景吧。近期公司在做一个车辆调度的项目&＃xff0c;需要使用消息队列。由于目前公司内部已经搭建了RocketMQ的集群服务&＃xff0c;运维那边建议利用现有的RocketMQ集群来做&＃xff0c;只需要建几个Topic就能使用了。因此&＃xff0c;在当前几个流行的消息队列中&＃xff0c;比方说RabbitMQ、RocketMQ、ActiveMQ、Kafka等&＃xff0c;选择了RocketMQ。对&＃xff0c;为什么选择RocketMQ&＃xff0c;原因就是这么简单&＃xff0c;运维省事啊&＃xff01;并没有什么大家想象的开会来讨论下性能、场景什么的。

       既然要用RocketMQ&＃xff0c;那就用呗。

       其实之前&＃xff0c;我对RocketMQ了解并不多&＃xff0c;如果说对某个消息队列更熟悉一点&＃xff0c;可能还是RabbitMQ&＃xff0c;因为RabbitMQ在大学里面就学习过&＃xff0c;搭建环境啊&＃xff0c;写写demo啊&＃xff0c;更熟练些&＃xff08;虽然长时间不用也忘的差不多了......&＃xff09;。

       不过这些都不重要&＃xff0c;重要的是技术人员都有一颗学习的心啊&＃xff01;不懂就学啊&＃xff0c;然后&＃xff0c;就学以致用啊&＃xff01;

       这篇文章不会介绍什么知识性东西&＃xff0c;仅仅作为RocketMQ的一个入门介绍&＃xff0c;知道他是什么&＃xff0c;干什么的&＃xff0c;为什么要用这个东西。

       RocketMQ出自阿里巴巴&＃xff0c;用 Java 语言实现&＃xff0c;在设计时参考了 Kafka&＃xff0c;并做出了自己的一些改进&＃xff0c;消息可靠性上比 Kafka 更好。比起Kafka的Scala语言和RabbitMQ的Erlang语言&＃xff0c;更容易找到技术人员进行定制开发。

       阿里的消息中间件有很长的历史&＃xff0c;从2007年的Notify到2010年的Napoli&＃xff0c;2011年升级为MetaQ&＃xff0c;然后到2012年开始做RocketMQ&＃xff0c;2016年&＃xff0c;阿里巴巴将RocketMQ捐赠给Apache基金会&＃xff0c;并于2017年9月成为Apache基金会的顶级项目。第一代的Notify主要使用了推模型&＃xff0c;解决了事务消息&＃xff1b;第二代的MetaQ主要使用了拉模型&＃xff0c;解决了顺序消息和海量堆积的问题。RocketMQ基于长轮询的拉取方式&＃xff0c;兼有两者的优点。

       在阿里内部&＃xff0c;RocketMQ很好地服务了集团大大小小上千个应用&＃xff0c;在每年的双十一当天&＃xff0c;更有不可思议的万亿级消息通过RocketMQ流转&＃xff08;在2017年的双十一当天&＃xff0c;整个阿里巴巴集团通过RocketMQ流转的线上消息达到了万亿级&＃xff0c;峰值TPS达到5600万&＃xff09;&＃xff0c;在阿里大中台策略中发挥着举足轻重的作用。

       学过数据结构我们都知道&＃xff0c;“队列”是一种先进先出的数据结构。

       简单来说&＃xff0c;消息队列就是基础数据结构课程里“先进先出”的数据结构。但是如果要消除单点故障&＃xff0c;保证消息传输的可靠性&＃xff0c;并且还能应对大流量的冲击&＃xff0c;对消息队列的要求就很高了。

三、为什么要使用消息队列       

       现在互联网“微架构”模式兴起&＃xff0c;原有大型集中式的IT服务因为各种弊端&＃xff0c;通常被分拆成细粒度的多个“微服务”&＃xff0c;这些微服务可以在一个局域网内&＃xff0c;也可能跨机房部署。一方面对服务之间松耦合的要求越来越高&＃xff0c;另一方面&＃xff0c;服务之间的联系却越来越紧密&＃xff0c;对通信质量要求也越来越高&＃xff0c;分布式消息队列可以提供应用解耦、流量消峰、消息分发等功能&＃xff0c;已经成为大型互联网服务架构里标配的中间件。

1、应用解耦

       复杂的应用会存在多个子系统&＃xff0c;比如在电商应用中有订单系统、库存系统、物流系统、支付系统等。这个时候如果各个子系统之间的耦合性太高&＃xff0c;整体系统的可用性就会大幅降低。多个低错误率的子系统强耦合在一起&＃xff0c;得到的是一个高错误率的整体系统。

       以电商应用为例&＃xff0c;用户创建订单后&＃xff0c;如果耦合调用库存系统、物流系统、支付系统&＃xff0c;任何一个子系统出了故障或者因为升级等原因暂时不可用&＃xff0c;都会造成下单操作异常&＃xff0c;影响用户使用体验。

        转变成基于消息队列的方式后&＃xff0c;系统可用性就高多了&＃xff0c;比如物流系统因为发生故障&＃xff0c;需要几分钟的时间来修复&＃xff0c;在这几分钟的时间里&＃xff0c;物流系统要处理的内容被缓存在消息队列里&＃xff0c;用户的下单操作可以正常完成。

       当物流系统恢复后&＃xff0c;补充处理存储在消息队列里的订单信息即可&＃xff0c;终端用户感知不到物流系统发生过几分钟的故障。

2、流量削峰

       仍然以电商系统为例&＃xff0c;每年的淘宝双十一、京东618等&＃xff0c;各大电商网站的活动都在0点准时开启&＃xff0c;应用系统的流量会瞬间猛增&＃xff0c;这个时候如果没有缓冲机制&＃xff0c;不可能承受住短时大流量的冲击。通过利用消息队列&＃xff0c;把大量的请求暂存起来&＃xff0c;分散到相对长的一段时间内处理&＃xff0c;能大大提高系统的稳定性和用户体验 。

       举个例子&＃xff0c;如果订单系统每秒最多能处理一万次下单&＃xff0c;这个处理能力应对正常时段的下单是绰绰有余的&＃xff0c;正常时段我们下单后一秒内就能返回结果。在购物节0点的时候&＃xff0c;如果没有消息队列这种缓冲机制&＃xff0c;为了保证系统稳定&＃xff0c;只能在订单超过1万次后就不允许用户下单了&＃xff1b;如果有消息队列做缓冲&＃xff0c;我们可以取消这个限制&＃xff0c;把一秒内下的订单分散成一段时间来处理&＃xff0c;这时有些用户可能在十几秒才能收到下单成功的状态&＃xff0c;但是也比不能下单的状态要好。

       使用消息队列进行流量消峰&＃xff0c;很多时候不是因为能力不够&＃xff0c;而是出于经济性的考量。比如有的业务系统&＃xff0c;流量最高峰也不会超过一万QPS&＃xff0c;而平时只有一千左右的QPS&＃xff0c;这种情况下我们就可以用个普通性能的服务器&＃xff08;只支持一千左右的 QPS 就可以&＃xff09;&＃xff0c;然后加个消息队列作为高峰期的缓冲&＃xff0c;无须花大笔资金部署能处理上万 QPS 的服务器。

3、消息分发

       在大数据时代&＃xff0c;数据对很多公司来说就像金矿&＃xff0c;公司需要依赖对数据的分析&＃xff0c;进行用户画像 、精准推送、流程优化等各种操作&＃xff0c;并且对处理的实时性要求越来越高。数据是不断产生的&＃xff0c;各个分析团队、算法团队都要依赖这些数据来进行工作&＃xff0c;这个时候有个可持久化的消息队列就非常重要。数据的产生方只需要把各自的数据写人一个消息队列即可&＃xff0c;数据使用方根据各自需求订阅感兴趣的数据&＃xff0c;不同数据团队所订阅的数据可以重复也可以不重复&＃xff0c;互不干扰&＃xff0c;也不必和数据产生方关联。

       除了应用解耦、流量消峰、消息分发等功能外&＃xff0c;消息队列还有保证最终一致性、方便动态扩容等功能。