消息中间件 消息中间件这么多，到底应该如何选型？

"

消息队列逐渐成为企业应用系统内部通信的核心手段。它具有低耦合、可靠传递、广播、流量控制、最终一致性等一系列功能。

目前消息队列中广泛使用的有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ等，而Redis、MySQL、PhxSQL等一些数据库也可以实现消息队列的功能。

消息队列概述

消息队列是指利用高效可靠的消息传递机制进行的与平台无关的数据交换，以及基于数据通信的分布式系统集成。

通过提供消息传递和消息队列模型，可以在分布式环境中提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等功能。作为分布式系统架构中的一个重要组成部分，它发挥着重要的作用。

消息队列的特征

采用异步处理方式

消息发送者可以发送消息而无需等待响应。消息发送方将消息发送到虚拟通道(主题或队列)，而消息接收方订阅或侦听该通道。

消息最终可能被转发给一个或多个消息接收者，这些接收者不需要同步地响应消息发送者。整个过程是异步的。

应用系统之间的解耦

主要体现在以下两点:

发送者和接受者不必了解对方、只需要确认消息。发送者和接受者不必同时在线。

例如，为了保证数据的最终一致性，在线交易系统会在支付系统处理完毕后将支付结果放入消息中间件，并通知订单系统修改订单支付状态。这两个系统通过消息中间件进行解耦。

消息队列的传递服务模型

消息队列的传递服务模型如下图所示:

消息队列的传输模式

点对点模型

点对点模型用于消息生产者和消息消费者之间的点对点通信。消息生产者将消息发送给由特定名称标识的特定消费者。

这个名称实际上是消费者服务中的一个队列，在消息被传递给消费者之前，它被存储在这个队列中。

队列消息可以存储在内存中或持久化，以确保消息服务失败时消息仍然可以被传递。

传统的点对点消息中间件通常由消息队列服务、消息传递服务、消息队列和消息应用程序接口API组成。

典型结构如下图所示:

特点如下:

每个消息只用一个消费者。发送者和接受者没有时间依赖。接受者确认消息接受和处理成功。

原理图如下:

发布/订阅模式(发布/订阅)

发布者/订阅者模型支持生成特定消息主题的消息。0个或更多订阅者可能有兴趣接收来自特定消息主题的消息。

在这种模式下，发布者和订阅者互不认识，就像匿名的公告牌一样。这种模式可以概括为:多个消费者可以获得消息，发布者和订阅者之间存在时间依赖。

出版商需要建立订阅，以便消费者可以订阅。订户必须保持持续活跃并接收消息。

在这种情况下，当订户未连接时，已发布的消息将在订户重新连接时重新发布，如下图所示:

特点如下:

每个消息可以有多个订阅者。客户端只有订阅后才能接收到消息。

请注意以下三点:

发布者和订阅者有时间依赖：接受者和发布者只有建立订阅关系才能收到消息。持久订阅：订阅关系建立后，消息就不会消失，不管订阅者是否都在线。非持久订阅：订阅者为了接受消息，必须一直在线。当只有一个订阅者时约等于点对点模式。

消息队列应用场景

当您需要使用消息队列时，您应该首先考虑它的必要性。可以使用消息队列的场景很多，其中最常用的是应用的松耦合、异步处理模式、发布订阅、最终一致性、峰值流量控制和日志缓冲等。

相反，如果需要很强的一致性，注重业务逻辑的处理结果，RPC更合适。

异步处理

异步非核心进程减少了系统响应时间并提高了吞吐量。比如:短信通知、终端状态推送、App推送、用户注册等。

消息队列通常具有内置的高效通信机制，因此它们也可以用于简单的消息通信，如点对点消息队列或聊天室。

应用案例:网站用户注册，注册成功后会发送邮件确认或短信。

系统解耦

系统不是强耦合的，消息接收者可以随意添加，无需修改消息发送者的代码。

消息发送方的成功不依赖于消息接收方(比如有些银行接口不稳定，但是调用方不需要依赖这些接口)。

不要依赖系统的非核心流程。对于非核心流程，可以放在消息队列中，供消息消费者按需消费，而不影响核心主流程。

最终一致性

最终一致性不是消息队列的必要特征，但可以通过消息队列来实现:

先写消息再操作，确保操作完成后再修改消息状态。定时任务补偿机制实现消息可靠发送接收、业务操作的可靠执行，要注意消息重复与幂等设计。所有不保证 100% 不丢消息的消息队列，理论上无法实现最终一致性。

对于卡夫卡这样的设计，在设计层面是有可能丢失消息的(比如定期刷盘，断电会丢失消息)。即使只有千分之一的消息丢失，商家也必须用其他手段来保证结果的正确。

广播

生产者/消费者模式只需要关心消息是否传递到队列中，谁想订阅谁需要消费是下游的事，这无疑大大降低了开发和联合调试的工作量。

流量峰值削波和流量控制

当上游和下游系统的处理能力之间存在差距时，消息队列被用作限流控制的通用“漏斗”。下游有能力处理时再分配。

比如用户在支付系统成功结算后，订单系统会通过短信系统向用户推送扣款通知。

由于短板效应，短信系统的速度卡在网关上(每秒几百个请求)，和前端的并发不是一个数量级的。因此，支付系统和短信系统的处理能力是不同的。

但是当用户晚上收到一分半钟左右的短信，一般不会有大问题。如果没有消息队列，两个系统之间的协商、滑动窗口等复杂方案就无法实现。

但是系统的复杂度呈指数级增长，必然会做上下游存储，处理定时、拥塞等一系列问题。

而每当处理能力出现缺口时，就需要单独开发一套逻辑来维护这套逻辑。

因此，利用中间系统转储两个系统之间的通信内容，然后在下游系统有能力处理这些消息时再处理这些消息，是一种比较常见的方式。

应用案例:

把消息队列当成可靠的消息暂存地，进行一定程度的消息堆积。定时进行消息投递，比如模拟用户秒杀访问，进行系统性能压测。

日志处理

在日志处理中使用消息队列，比如卡夫卡，解决海量日志传输和缓冲的问题。

应用案例:集中收集日志，用于PV计算、用户行为分析等。

消息通信

消息队列通常具有内置的高效通信机制，因此它们也可以用于简单的消息通信，如点对点消息队列或聊天室。

消息队列的推拉模型

推送推送消息模型

消息生产者将消息发送到消息队列，消息队列又将消息推送给消息消费者。

拉拉消息模型

消费者请求消息队列接受消息，消息生产者从消息队列中提取消息。

两种类型的区别

这两种类型的区别如下:

消息队列技术的比较

本节主要介绍四种常用的消息队列(ActiveMQ/Rabbit MQ/Rockemq/Kafka)的主要特点和优缺点。

消息中间件

ActiveMQ是Apache生产的。ActiveMQ是一个JMS提供者实现，完全支持JMS1.1和J2EE1.4规范。

它速度非常快，支持多语言客户端和协议，可以很容易地嵌入到企业应用环境中，并且具有许多高级功能。

主要特点:

服从 JMS 规范：JMS 规范提供了良好的标准和保证，包括：同步或异步的消息分发，一次和仅一次消息分发，消息接收和订阅等等。 遵从 JMS 规范的好处在于，不论使用什么 JMS 实现提供者，这些基础特性都是可用的。连接灵活性：ActiveMQ 提供了广泛的连接协议，支持的协议有：HTTP/S，IP 多播，SSL，TCP，UDP 等等。对众多协议的支持让 ActiveMQ 拥有了很好的灵活性。支持的协议种类多：OpenWire、STOMP、REST、XMPP、AMQP。持久化插件和安全插件：ActiveMQ 提供了多种持久化选择。而且， ActiveMQ 的安全性也可以完全依据用户需求进行自定义鉴权和授权。支持的客户端语言种类多：除了 Java 之外，还有 C/C++，.Net，Perl， PHP，Python，Ruby。代理集群：多个 ActiveMQ 代理可以组成一个集群来提供服务。异常简单的管理：ActiveMQ 是以开发者思维被设计的。所以，它并不需要专门的管理员，因为它提供了简单又实用的管理特性。 有很多种方法可以监控 ActiveMQ 不同层面的数据，包括使用在 JConsole 或者在 ActiveMQ 的 WebConsole 中使用 JMX。 通过处理 JMX 的告警消息，通过使用命令行脚本，甚至可以通过监控各种类型的日志。

部署环境:ActiveMQ可以在Java语言支持的平台上运行。

使用主动式MQ需要:

JavaJDKActiveMQ 安装包

优点如下:

跨平台（Java 编写与平台无关，ActiveMQ 几乎可以运行在任何的 JVM上）。可以用 JDBC：可以将数据持久化到数据库。虽然使用 JDBC 会降低 ActiveMQ 的性能，但是数据库一直都是开发人员最熟悉的存储介质。支持 JMS 规范：支持 JMS 规范提供的统一接口。支持自动重连和错误重试机制。有安全机制：支持基于 Shiro，JAAS 等多种安全配置机制，可以对 Queue/Topic 进行认证和授权。监控完善：拥有完善的监控，包括 WebConsole，JMX，Shell 命令行， Jolokia 的 RESTfulAPI。界面友善：提供的 WebConsole 可以满足大部分情况，还有很多第三方的组件可以使用，比如 Hawtio。

缺点如下:

社区活跃度不及 RabbitMQ 高。根据其他用户反馈，会出莫名其妙的问题，会丢失消息。目前重心放到 ActiveMQ 6.0 产品 Apollo，对 5.x 的维护较少。不适合用于上千个队列的应用场景。

RabbitMQ

RabbitMQ于2007年发布，是基于AMQP(高级消息队列协议)的可重用企业消息系统，是目前最主流的消息中间件之一。

主要特点如下:

可靠性：提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制。灵活的路由：消息在到达队列前是通过交换机进行路由的。RabbitMQ 为典型的路由逻辑提供了多种内置交换机类型。 如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做 RabbitMQ 的插件来使用。消息集群：在相同局域网中的多个 RabbitMQ 服务器可以聚合在一起，作为一个独立的逻辑代理来使用。队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全。支持多种协议：支持多种消息队列协议。支持多种语言：用 Erlang 语言编写，支持只要是你能想到的所有编程语言。管理界面：RabbitMQ 有一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。跟踪机制：如果消息异常， RabbitMQ 提供消息跟踪机制，使用者可以找出发生了什么。插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

部署环境:RabbitMQ可以在Erlang语言支持的平台上运行，包括Solaris、BSD、Linux、MacOSX、TRU64、Windows等。

RabbitMQ的使用要求:

ErLang 语言包RabbitMQ 安装包

优点如下:

由于 Erlang 语言的特性，消息队列性能较好，支持高并发。健壮、稳定、易用、跨平台、支持多种语言、文档齐全。有消息确认机制和持久化机制，可靠性高。高度可定制的路由。管理界面较丰富，在互联网公司也有较大规模的应用，社区活跃度高。

缺点如下:

尽管结合 Erlang 语言本身的并发优势，性能较好，但是不利于做二次开发和维护。实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得 RabbitMQ 易于使用和部署，但是使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大。需要学习比较复杂的接口和协议，学习和维护成本较高。

消息队列

RocketMQ来自阿里的开源产品，用Java语言实现。设计上参考了卡夫卡，做了一些自己的改进。消息可靠性比卡夫卡好。

RocketMQ广泛应用于阿里的订单、交易、充值、流计算、消息推送、日志流处理、Binglog分发等场景。

主要特点如下:

基于队列模型：具有高性能、高可靠、高实时、分布式等特点。Producer、Consumer 队列都支持分布式。Producer 向一些队列轮流发送消息，队列集合称为 Topic。Consumer 如果做广播消费，则一个 Consumer 实例消费这个 Topic 对应的所有队列。 如果做集群消费，则多个 Consumer 实例平均消费这个 Topic 对应的队列集合。能够保证严格的消息顺序。提供丰富的消息拉取模式。高效的订阅者水平扩展能力。实时的消息订阅机制。亿级消息堆积能力。较少的外部依赖。

部署环境:RocketMQ可以在Java语言支持的平台上运行。

使用RocketMQ需要:

JavaJDK安装 Git、MavenRocketMQ 安装包

优点如下:

单机支持 1 万以上持久化队列。RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，而访问时，直接从内存读取。模型简单，接口易用（ JMS 的接口很多场合并不太实用）。性能非常好，可以允许大量堆积消息在 Broker 中。支持多种消费模式，包括集群消费、广播消费等。各个环节分布式扩展设计，支持主从和高可用。开发度较活跃，版本更新很快。

缺点如下:

支持的客户端语言不多，目前是 Java 及 C++，其中 C++ 还不成熟。RocketMQ 社区关注度及成熟度也不及前两者。没有 Web 管理界面，提供了一个 CLI（命令行界面）管理工具带来查询、管理和诊断各种问题。没有在 MQ 核心里实现 JMS 等接口。

卡夫卡

Apache Kafka是一个分布式消息发布和订阅系统。它最初是由LinkedIn基于其独特的设计实现为分布式提交日志，后来成为Apache项目的一部分。

卡夫卡高效、可伸缩、耐用。它的分区特性、可复制性、容错性都是很好的特性。

主要特点如下:

快速持久化：可以在 O(1) 的系统开销下进行消息持久化。高吞吐：在一台普通的服务器上即可以达到 10W/S 的吞吐速率。完全的分布式系统：Broker、Producer 和 Consumer 都原生自动支持分布式，自动实现负载均衡。支持同步和异步复制两种高可用机制。支持数据批量发送和拉取。零拷贝技术（zero-copy）：减少 IO 操作步骤，提高系统吞吐量。数据迁移、扩容对用户透明。无需停机即可扩展机器。其他特性：丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制。

部署环境，使用卡夫卡要求:

JavaJDKKafka 安装包

优点如下:

客户端语言丰富：支持 Java、.Net、PHP、Ruby、Python、Go 等多种语言。高性能：单机写入 TPS 约在 100 万条/秒，消息大小 10 个字节。提供完全分布式架构，并有 Replica 机制，拥有较高的可用性和可靠性，理论上支持消息无限堆积。支持批量操作。消费者采用 Pull 方式获取消息。消息有序，通过控制能够保证所有消息被消费且仅被消费一次。有优秀的第三方 Kafka Web 管理界面 Kafka-Manager。在日志领域比较成熟，被多家公司和多个开源项目使用。

缺点如下:

Kafka 单机超过 64 个队列/分区时， Load 时会发生明显的飙高现象。队列越多，负载越高，发送消息响应时间变长。使用短轮询方式，实时性取决于轮询间隔时间。消费失败不支持重试。支持消息顺序，但是一台代理宕机后，就会产生消息乱序。社区更新较慢。

几种消息队列的比较

以下是上述四种消息队列之间的差异比较:

卡夫卡在于分布式架构，RabbitMQ是基于AMQP协议实现的，RocketMQ的思想来源于卡夫卡，改成主从结构，在事务和可靠性方面进行优化。

一般来说，电子商务，金融等。对事务一致性要求高的可以考虑RabbitMQ和RocketMQ，对性能要求高的可以考虑卡夫卡。

总结

介绍了消息队列的特点、消息队列的传递服务模型、消息的传输模式和消息的推拉模式。

然后，介绍了几种常见的消息队列，如ActiveMQ、RabbitMQ、RocketMQ和Kafka，并阐述了各种消息队列的主要特点和优缺点。

通过这篇文章，相信你会对消息队列的选择和相关技术有更深入的了解。更多细节和原理，需要在实践中看到真知！

简介:五年在R&D和建筑方面的经验。曾在思爱普中国R&D中心和上海冰建科技信息技术有限公司后端R&D担任建筑师助理，现为成都思爱普工程有限公司高级顾问和R&D员工..熟悉大数据、高并发、负载均衡、缓存、数据库、消息中间件、搜索引擎、容器、自动化。个人学习能力强，技术热情高，热爱开源和写技术博客，善于沟通和分享。

来源:转载自微信微信官方账号:零技术栈(ID:零一技术)