IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列

1、引言

消息是互联网信息的一种表现形式，是人利用计算机进行信息传递的有效载体，比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。

消息从发送者到接收者的典型传递方式有两种：

• 1）一种我们可以称为即时消息：即消息从一端发出后（消息发送者）立即就可以达到另一端（消息接收者），这种方式的具体实现就是平时最常见的IM聊天消息；
• 2）另一种称为延迟消息：即消息从某端发出后，首先进入一个容器进行临时存储，当达到某种条件后，再由这个容器发送给另一端。
  

在上述“消息传递方式2）”中所指的这个容器的一种具体实现就是MQ消息队列服务。

MQ消息队列中间件是中大型分布式系统中重要的组件，它主要用来解决：应用解耦、异步消息、流量削锋等问题，用以实现高性能、高可用、可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等。MQ消息队列中间件已被广泛用于电商、即时通讯、社交等各种中大型分布式应用系统。


▲ 各种MQ消息队列，玲琅满目

在一个典型的IM即时通讯应用中，MQ消息队列可以用于：

• 1）用户的聊天消息离线存储环节：因为IM消息的发送属于高吞吐场景，直接操纵DB很容易就把DB搞挂了，所以离线消息在落地入库前，可以先扔到MQ消息队列中，再由单独部署的消费者来有节奏地存储到DB中；
• 2）用户的行为数据收集环节：因为用户的聊天消息和指令等，可以用于大数据分析，而且基于国家监管要求也是必须要存储一段时间的，所以此类数据的收集同样可以用于MQ消息队列，再由单独部署的消费者存储到DB中；
• 3）用户的操作日志收集环节：log这种数据价值不高，但关键时刻又非常有用，而且数据量又很大，要想存储起来难度很高，这时就轮到Linkedin公司开源的Kafka出场了；
• ....
  

因此，对于即时通讯开发者来说，正确地理解MQ消息队列，对于IM或消息推送系统的架构设计、方案选型等都大有裨益。


▲ 一个典型的消息队列原理图（生产者将消息通过队列传递给消费者）

* 推荐阅读相关文章：

• 《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
• 《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
  

2、系列文章

▼ IM开发干货系列文章（本文是其第16篇）：

• 《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
• 《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
• 《如何保证IM实时消息的“时序性”与“一致性”？》
• 《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
• 《IM群聊消息如此复杂，如何保证不丢不重？》
• 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
• 《移动端IM登录时拉取数据如何作到省流量？》
• 《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
• 《浅谈移动端IM的多点登陆和消息漫游原理》
• 《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
• 《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
• 《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
• 《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
• 《IM群聊消息的已读回执功能该怎么实现？》
• 《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
• 《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》（本文）
• 《一个低成本确保IM消息时序的方法探讨》
• 《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
• 《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
• 《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
• 《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
• 《IM的扫码登功能如何实现？一文搞懂主流应用的扫码登陆技术原理》
• 《IM要做手机扫码登陆？先看看微信的扫码登录功能技术原理》
• 《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
• 《IM开发实战干货：我是如何解决大量离线聊天消息导致客户端卡顿的》
• 《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
• 《IM开发基础知识补课(十)：大型IM系统有多难？万字长文，搞懂异地多活！》
  

如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

3、MQ消息队列的典型应用场景

MQ消息队列目前在中大型分布式系统实际应用中常用的使用场景主要有：异步处理、应用解耦、流量削锋和消息通讯四个场景。

3.1应用场景1：异步处理

场景说明：一个典型的IM即时通讯系统中，用户注册成功后可能需要发送注册邮件和注册通知短信。

传统的做法有两种：

• 1）串行的方式：即将注册信息写入数据库成功后、发送注册邮件、再发送注册短信。以上三个任务全部完成后，返回给客户端；
• 2）并行方式：即将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。
  

假设三个业务节点每个使用50毫秒，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。

因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）。

小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。

如何解决这个问题呢？答案是：引入消息队列，将不是必须的业务逻辑，异步处理。

改造后的架构如下：


按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。

3.2应用场景2：应用解耦

场景说明：一个典型的电商购物系统中，用户下订单后，订单系统需要通知库存系统。

传统的做法是：订单系统调用库存系统的接口。如下图所示：


传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合。

如何解决以上问题呢？答案是：引入应用消息队列后的方案。如下图：


如上图所示，大致的原理是：

• 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功；
• 库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。
  

好处就是：假如在下单时库存系统不能正常使用，也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

3.3应用场景3：流量削锋

流量削锋也是消息队列中的常用场景，一般在电商秒杀等大型活动（比如双11）、团购抢单活动中使用广泛。

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

在这种场景下加入消息队列服务的好处：

• 1）可以控制活动的人数；
• 2）可以缓解短时间内高流量压垮应用。
  

▲ 原理图如上图所示

用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。秒杀业务根据消息队列中的请求信息，再做后续处理。

3.4应用场景4：日志处理

日志处理是指将消息队列用在日志处理中，比如Linkedin这种大型职业社交应用架构中Kafka的应用（Kafka就是Linkedin开发并开源的），解决大量日志传输的问题。

使用Kafka后的架构简化如下：


上图所示的架构原理就是：

• 日志采集客户端：负责日志数据采集，定时写入Kafka队列；
• Kafka消息队列：负责日志数据的接收，存储和转发；
• 日志处理应用：订阅并消费kafka队列中的日志数据。
  

3.5应用场景5：即时消息通讯

即时消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的即时消息通讯场景。比如实现点对点消息队列或者IM聊天室等（但Jack Jiang认为，在中大型IM系统中，MQ并不适合这么用，具体的讨论请见：《请教可以使用MQ消息队列中间件做即时通讯系统吗？》）。

• 点对点通讯：客户端A和客户端B使用同一队列，进行消息通讯；
• 聊天室通讯：客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。
  

以上实际是消息队列的两种消息模式，点对点或发布订阅模式。模型为示意图，供参考。

4、MQ消息队列的常见消息模式

常见的MQ消息队列消息模式有：

• 1）P2P模式；
• 2）Pub/sub模式（也就是常说的“发布/订阅”模式）；
• 3）推(Push)模式和拉(Pull)模式。
  

下面将逐个介绍这几种常消息模式。

4.1P2P模式

▲ 典型的P2P消息模式原理图

P2P模式包含三个角色：

• 1）消息队列（Queue）；
• 2）发送者(Sender)；
• 3）接收者(Receiver)。
  

每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

P2P消息模式的特点：

每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列接收者在成功接收消息之后需向队列应答成功 如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式。

4.2Pub/sub模式

▲ 典型的Pub/sub消息模式原理图

如上图所示，此消息模式包含三个角色：

• 1）主题（Topic）；
• 2）发布者（Publisher）；
• 3）订阅者（Subscriber）。
  

多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

Pub/Sub的特点：

每个消息可以有多个消费者发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。为了消费消息，订阅者必须保持运行的状态。为了缓和这样严格的时间相关性，有些MQ消息队列（比如RabbitMQ）允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。

4.3推模式和拉模式

▲ 一个典型的推模式和拉模式原理图

推(push)模式是一种基于C/S机制、由服务器主动将信息送到客户器的技术。

在Push模式应用中，服务器把信息送给客户器之前，并没有明显的客户请求。push事务由服务器发起。push模式可以让信息主动、快速地寻找用户/客户器，信息的主动性和实时性比较好。但精确性较差，可能推送的信息并不一定满足客户的需求。

Push模式不能保证能把信息送到客户器，因为推模式采用了广播机制，如果客户器正好联网并且和服务器在同一个频道上，推送模式才是有效的。

Push模式无法跟踪状态，采用了开环控制模式，没有用户反馈信息。在实际应用中，由客户器向服务器发送一个申请，并把自己的地址（如IP、port）告知服务器，然后服务器就源源不断地把信息推送到指定地址。在多媒体信息广播中也采用了推模式。

拉(Pull)模式与推(Push)模式相反，是由客户器主动发起的事务。服务器把自己所拥有的信息放在指定地址（如IP、port），客户器向指定地址发送请求，把自己需要的资源“拉”回来。不仅可以准确获取自己需要的资源，还可以及时把客户端的状态反馈给服务器。

5、主流的MQ消息队列技术选型对比

一份主流MQ技术对比清单：


另外，即时通讯网整理的另一篇《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》，可以详细了解一下Kafka和RabbitMQ的对比。

5.1Kafka

Kafka是Linkedin开源的MQ系统（现已是Apache下的一个子项目），它是一个高性能跨语言分布式发布/订阅消息队列系统，主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，0.8开始支持复制，不支持事务，适合产生大量数据的互联网服务的数据收集业务。

Kafka还具有以下特性：

• 1）快速持久化，可以在O(1)的系统开销下进行消息持久化；
• 2）高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；
• 3）完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；
• 4）支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。
  

Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

5.2RabbitMQ

RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

RabbitMQ本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

5.3RocketMQ

RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

5.4ZeroMQ

ZeroMQ只是一个网络编程的Pattern库，将常见的网络请求形式（分组管理，链接管理，发布订阅等）模式化、组件化，简而言之socket之上、MQ之下。对于MQ来说，网络传输只是它的一部分，更多需要处理的是消息存储、路由、Broker服务发现和查找、事务、消费模式（ack、重投等）、集群服务等。

ZeroMQ是号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块）。

5.5小结

RabbitMQ/Kafka/ZeroMQ 都能提供消息队列服务，但有很大的区别。

在面向服务架构中通过消息代理（比如 RabbitMQ / Kafka等），使用生产者-消费者模式在服务间进行异步通信是一种比较好的思想。

因为服务间依赖由强耦合变成了松耦合。消息代理都会提供持久化机制，在消费者负载高或者掉线的情况下会把消息保存起来，不会丢失。就是说生产者和消费者不需要同时在线，这是传统的请求-应答模式比较难做到的，需要一个中间件来专门做这件事。其次消息代理可以根据消息本身做简单的路由策略，消费者可以根据这个来做负载均衡，业务分离等。

缺点也有，就是需要额外搭建消息代理集群（但优点是大于缺点的 ） 。

ZeroMQ 和 RabbitMQ/Kafka 不同，它只是一个异步消息库，在套接字的基础上提供了类似于消息代理的机制。使用 ZeroMQ 的话，需要对自己的业务代码进行改造，不利于服务解耦。

RabbitMQ 支持 AMQP（二进制），STOMP（文本），MQTT（二进制），HTTP（里面包装其他协议）等协议。Kafka 使用自己的协议。

Kafka 自身服务和消费者都需要依赖 Zookeeper。

RabbitMQ 在有大量消息堆积的情况下性能会下降，Kafka不会。毕竟AMQP设计的初衷不是用来持久化海量消息的，而Kafka一开始是用来处理海量日志的。

总的来说，RabbitMQ 和 Kafka 都是十分优秀的分布式的消息代理服务，只要合理部署，基本上可以满足生产条件下的任何需求。

关于这两种MQ的比较，网上的资料并不多，最权威的的是kafka的提交者写一篇文章：http://www.quora.com/What-are-the-differences-between-Apache-Kafka-and-RabbitMQ

这篇文间里面提到的要点：

• 1） RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka；
• 2） Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性；
• 3） Kafka的性能（吞吐量、tps）比RabbitMq要强，这篇文章的作者认为，两者在这方面没有可比性；
• 4）总的来说，目前RocketMq、Kafka、RabbitMq在各家公司都有使用，具体看技术团队的熟悉程度及使用场景了。
  

附录1：有关IM即时通讯架构设计的文章

《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
>> 更多同类文章 ……

附录2：有关IM即时通讯的更多热点问题的文章

《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《小白必读：闲话HTTP短连接中的Session和Token》
《IM开发基础知识补课：正确理解前置HTTP SSO单点登陆接口的原理》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《一个低成本确保IM消息时序的方法探讨》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《谈谈移动端 IM 开发中登录请求的优化》
《移动端IM登录时拉取数据如何作到省流量？》
《浅谈移动端IM的多点登陆和消息漫游原理》
《完全自已开发的IM该如何设计“失败重试”机制？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《为什么说即时通讯社交APP创业就是一个坑？》
《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移动端主流图片格式的特点、性能、调优等》
《最火移动端跨平台方案盘点：React Native、weex、Flutter》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
>> 更多同类文章 ……

收获很大，谢谢

学习了

非常好

这篇文章很好，终于把这些鬼mq搞明白了