白话讲解：消息队列到底解决了什么问题？



2020年处于移动互联网的下半场，各种技术层出不穷，虽然数据也在爆发式增长，但是高并发、高吞吐已经不再是首要的痛点，稳定、可靠才是王道。

本文作为一篇消息队列入门级介绍，帮助大家对消息队列有一个大致的了解，并对对时下流行的消息队列组件进行了简单的比较，供大家做技术选型的参考。



1  什么是消息队列



消息队列（Message Queue），从广义上讲是一种消息队列服务中间件，提供一套完整的信息生产、传递、消费的软件系统。





消息队列所涵盖的功能远不止于队列（Queue），其本质是两个进程传递信息的一种方法。两个进程可以分布在同一台机器上，亦可以分布在不同的机器上。



众所周知，进程通信可以通过RPC（Remote Procedure Call，远程过程调用）进行，那么我们为什么要用消息队列这种软件服务来传递消息呢？



下面我们以春节订火车票为例进行说明，流程如下。



拿到年终奖了，准备买车票带着媳妇儿回家过年。你打开12306手机App开始做如下操作：



第一步：输入车票信息，发送订票请求。

起点站：北京。

终点站：成都。

出发时间：腊月29晚上8点。

票数：2张。

座席：硬卧。



第二步：单击“预订”按钮，12306 App界面开始转圈圈。与此同时全国3亿人民也在和你一起做相同的事情。



第三步：3s后，应用告诉你订票失败。



第四步：你修改车次，重新发送订票请求。应用重复第二步继续等待。又一个3s后，12306 App告诉你订票成功。





12306 App在处理上图逻辑时，会遇到以下挑战：



（1）今天这个车次只售出4000张票，而实际有30万人发送了订票信息，如果逐一请求处理，那么90%以上的人都将要耗时3s来等待，怎么办？



（2）下游有20个系统需要在订票成功后进行通知，如果逐一调用这些系统的接口进行通知，而其中一个通知任务执行失败，那么已经通知成功的任务会怎样？



（3）12306 App架构会不断调整，当数据结构发生变化时，下游20个系统都随着一起变化吗？

以上只是随机列举了一些常见的问题，如何才能优雅地处理呢？



答案是：消息队列！



2  为什么需要消息队列



我们平时什么时候可能会用到消息队列呢？下面结合刚才的流程图来介绍消息队列的适用场景。



▊ 削峰填谷 

业务系统在超高并发场景中，由于后端服务来不及同步处理过多、过快的请求，可能导致请求堵塞，严重时可能由于高负荷拖垮Web服务器。





我们都希望流量如上图虚线部分一样一直比较平稳，这样我们的系统也会更加稳定。但是实际的流量会随着时间不短变化，像12306 App这样的App流量大得难以想象，而一年中不同的时间段，其流量也不同。为了能支持最高峰流量，我们通常采取短平快的方式——直接扩容服务器，增加服务端的吞吐量。



优点是显而易见的，短时间内吞吐量增加了好几倍，甚至数十倍。缺点也明显，流量低峰期服务器相对较闲。



如何平衡平时的空闲与节假日的超高峰呢？我们想到了消息队列（比如Apache RocketMQ，Apache Kafka），也是目前业界比较常用的手段。利用消息队列扭转处理订票请求，告知用户30min内会告诉他/她订票结果。优缺点明显：性能提升了，但是我们作为业务开发人员，还要维护一个消息队列服务，人手完全不够。消息中间件呼之欲出。



▊ 程序间解耦 

不同的业务端在联合开发功能时，常常由于排期不同、人员调配不方便等原因导致项目延期。其实，其根本原因是业务耦合过度。



下图中，上下游系统之间的通信是彼此依赖的，所以不得不协调上下游所有的资源同步进行，跨团队处理问题显然比在团队内部处理问题难度大。





你是否依稀记得另一个团队的同事调用你的API，你告诉他发个请求过来，你打断点一步一步调试代码的场景？



你是否记得为了协调开发资源、QA资源，以及协调上线时间等所做的一切，你被老板骂了多少次，最后还是延期了：我们依赖他们，他们的QA说，高峰期不让发布。



加入消息队列后，不同的业务端又会是何种情况呢？





上下游系统进行开发、联调、上线，彼此完全不依赖，也就是说，系统间解耦了。



▊ 异步处理 

处理订票请求是一个漫长的过程，需要检查预订的车次是否有预订数量的票、下单扣库存、更新缓存等一系列操作。这些耗时的操作，我们可以通过使用消息队列的方式，把提交请求成功的消息告诉用户。然后异步处理这些耗时的操作，保证30min内能把处理的结果通过短信推送给用户，否则系统处理多久，用户就会等多久。



▊ 数据的最终一致性 

我们举例说明。很怀念每月的1号，可以向老婆的“财务部”缴费了。你的工资在招商银行，你老婆的工资在北京银行。通常，两个系统的通信过程如下。





如果通信失败，怎么保证你的钱“上交”了呢？业内常用的手段就是消息队列。消息系统的优点：



（1）免去了招商银行App多次重试（发起请求）的复杂逻辑。

（2）免去了北京银行App处理过多重试请求的压力。

（3）即使北京银行服务不可用，业务也不受影响。



3  常见消息队列



这里对时下流行的消息队列组件进行了简单的比较，供大家做技术选型的参考。



Apache RocketMQ是一款开源的、分布式的消息投递与流数据平台。出生自阿里巴巴，经历了近十年双11核心交易链路打磨，可以支撑万亿级消息洪峰。



作为Apache顶级开源项目之一，其在GitHub上有10000+ star、5000+ fork、170+ contributors（在GitHub上提交代码并被采纳的开发者），目前中国互联网、金融等行业Top级企业75%以上都在使用，已经成为云原生时代企业上云的核心基础设施！



学习掌握Apache RocketMQ，博文菌强烈推荐《RocketMQ分布式消息中间件：核心原理与最佳实践》一书。

李伟 著

作者有多年分布式系统的实战经验，特别是在消息队列方面经验丰富。本书根据作者在项目中使用RocketMQ的实际经验，结合实际源码，由浅入深地讲解了RocketMQ核心功能的具体实现逻辑，并从消息队列的应用场景出发，使读者快速地了解MQ解决的问题域。



通过阅读本书，不仅可以了解如何在项目中使用消息队列，还能学习到RocketMQ的实现细节，进一步提升对RocketMQ系统本身的把控力度。



▼扫码了解本书详情▼