RocketMQ修炼之路（一）：初识RocketMQ

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

       既然要用RocketMQ，那就用呗。

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

       不过这些都不重要，重要的是技术人员都有一颗学习的心啊！不懂就学啊，然后，就学以致用啊！

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

一、RocketMQ的前世今生

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

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

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

二、什么是消息队列

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

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

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

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

1、应用解耦

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

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

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

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

2、流量削峰

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

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

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

3、消息分发

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

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