1.揭开消息中间件RabbitMQ的神秘面纱

时间 2019-11-06

标签揭开消息中间件 rabbitmq 神秘面纱栏目 RabbitMQ 繁體版

原文原文链接

当你看到这篇博文的时候，相信你至少已经知道RabbitMQ 是一个很是优秀的消息中间件，它使用专门处理高并发的Erlang 语言编写而成的消息中间件产品。html

固然若是你不知道也不要紧，读完本篇你将Get 如下技能：java

为何须要消息中间件？

什么是生产者？

什么是消费者？

什么是队列？

什么是消息队列？

什么是消息中间件？

消息中间件有哪些？

了解什么时候使用RabbitMQ或Apache Kafka?

什么是RabbitMQ？

0x01 为何须要消息中间件?

Web 应用都是基于 HTTP 协议的请求/响应模式，没法像 TCP 协议那样保持长链接，所以 Web 应用就很难像手机那样实现实时的消息推送。node

就目前来看，Web 应用的消息推送方式主要有如下几种：shell

1.Ajax 短轮询

Ajax 轮询主要经过页面端的 JS 定时异步刷新任务来实现数据的加载，但这种方式实时效果较差，并且对服务端的压力也较大。数据库

2. 长轮询

长轮询主要也是经过 Ajax 机制，但区别于传统的 Ajax 应用，长轮询的服务器端会在没有数据时阻塞请求直到有新的数据产生或者请求超时才返回，以后客户端再从新创建链接获取数据，具体实现方式见图 1 所示。但长轮询服务端会长时间地占用资源，若是消息频繁发送的话会给服务端带来较大的压力。apache

图 1. 长轮询实现方式编程

3.WebSocket 双向通讯

WebSocket 是 HTML5 中一种新的通讯协议，可以实现浏览器与服务器之间全双工通讯。若是浏览器和服务端都支持 WebSocket 协议的话，该方式实现的消息推送无疑是最高效、简洁的。而且最新版本的 IE、Firefox、Chrome 等浏览器都已经支持 WebSocket 协议，Apache Tomcat 7.0.27 之后的版本也开始支持 WebSocket。浏览器

参考基于 RabbitMQ 的实时消息推送安全

0x02 消息传递术语

2.1 什么是生产者?

制做意味着发送。一个发送消息的程序是一个生产者：服务器

Tips: P 表明生产者

2.2 什么是消费者？

消费与接受有相似的意义。消费者是一个主要等待接收消息的程序：

请注意，生产者，消费者和中间件没必要驻留在同一主机上;

2.3 什么是队列？

队列是生活在RabbitMQ中的邮箱的名称。尽管消息流经RabbitMQ和您的应用程序，但它们只能存储在队列中。
一个队列只受主机内存和磁盘限制的约束，它本质上是一个很大的消息缓冲区。
许多生产者能够发送进入一个队列的消息，而且许多消费者能够尝试从一个队列接收数据。这就是咱们表明队列的方式：

2.4 什么是消息队列？

消息队列（Message Queue）是一种应用间的通讯方式，消息发送后能够当即返回，由消息系统来确保消息的可靠传递。

消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ中取消息而无论是谁发布的。这样发布者和使用者都不用知道对方的存在。

2.5 什么是消息中间件？

消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通讯来进行分布式系统的集成。

经过提供消息传递和消息排队模型，它能够在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通讯、数据同步等等功能，

其做为分布式系统架构中的一个重要组件，有着举足轻重的地位.

传统的信息系统做法多是收到一条消息就立刻同步存入数据库，这种做法在小并发量的状况下能够很好的工做，但互联网大并发环境下就是灾难.

更多解释请参考：消息队列之 RabbitMQ

2.6 其余概念

概念：

Brocker：消息队列服务器实体。
Exchange：消息交换机，指定消息按什么规则，路由到哪一个队列。
Queue：消息队列，每一个消息都会被投入到一个或者多个队列里。
Binding：绑定，它的做用是把exchange和queue按照路由规则binding起来。
Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
Vhost：虚拟主机，一个broker里能够开设多个vhost，用做不用用户的权限分离。
Producer：消息生产者，就是投递消息的程序。
Consumer：消息消费者，就是接受消息的程序。
Channel：消息通道，在客户端的每一个链接里，可创建多个channel，每一个channel表明一个会话任务。

消息队列的使用过程大概以下：

消息接收
- 客户端链接到消息队列服务器，打开一个channel。
- 客户端声明一个exchange，并设置相关属性。
- 客户端声明一个queue，并设置相关属性。
- 客户端使用routing key，在exchange和queue之间创建好绑定关系。
消息发布
- 客户端投递消息到exchange。
- exchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。

Exchange 和 Queue
绿色的 X 就是 Exchange ，红色的是 Queue ，这二者都在 Server 端，又称做 Broker
这部分是 RabbitMQ 实现的，而蓝色的则是客户端，一般有 Producer 和 Consumer 两种类型。

fanout：该类型路由规则很是简单，会把全部发送到该Exchange的消息路由到全部与它绑定的Queue中，至关于广播功能
direct：该类型路由规则会将消息路由到binding key与routing key彻底匹配的Queue中
topic：与direct类型类似，只是规则没有那么严格，能够模糊匹配和多条件匹配
headers：该类型不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配

0x03 消息中间件有哪些？

ActiveMQ 是 Apache 出品的、采用 Java 语言编写的彻底基于 JMS1.1 规范的面向消息的中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通讯。不过因为历史缘由包袱过重，目前市场份额没有后面三种消息中间件多，其最新架构被命名为 Apollo，号称下一代 ActiveMQ，有兴趣的同窗可行了解。

RabbitMQ 是采用 Erlang 语言实现的 AMQP 协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。RabbitMQ 发展到今天，被愈来愈多的人承认，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。

Kafka 起初是由 LinkedIn 公司采用 Scala 语言开发的一个分布式、多分区、多副本且基于 zookeeper 协调的分布式消息系统，现已捐献给 Apache 基金会。它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被普遍使用。目前愈来愈多的开源分布式处理系统如 Cloudera、Apache Storm、Spark、Flink 等都支持与 Kafka 集成。

RocketMQ 是阿里开源的消息中间件，目前已经捐献个 Apache 基金会，它是由 Java 语言开发的，具有高吞吐量、高可用性、适合大规模分布式系统应用等特色，经历过双 11 的洗礼，实力不容小觑。

ZeroMQ 号称史上最快的消息队列，基于 C 语言开发。ZeroMQ 是一个消息处理队列库，可在多线程、多内核和主机之间弹性伸缩，虽然大多数时候咱们习惯将其纳入消息队列家族之中，可是其和前面的几款有着本质的区别，ZeroMQ 自己就不是一个消息队列服务器，更像是一组底层网络通信库，对原有的 Socket API 上加上一层封装而已。

目前市面上的消息中间件还有不少，好比腾讯系的 PhxQueue、CMQ、Kafka 等，甚至NoSQL Redis听说也有消息队列的功能。

参考博文：IM系统的MQ消息中间件选型：Kafka仍是RabbitMQ？

0x04 了解什么时候使用RabbitMQ或Apache Kafka?

英文原文：Understanding When to use RabbitMQ or Apache Kafka

人们作出选择，情绪和我的喜爱每每是很是重要的因素，可是做为一个有经验的技术专家来讲，确定是不能由于我的喜爱去草率作出决定的。

现在市场上有数十种消息传递技术，什么样的场景用什么技术，这是一个技术专家应该考虑的问题。

现在最流行的选择有两种：RabbitMQ和Apache Kafka

因此接下来咱们将从起源，设计意图，成功的案例，集成的功能和开发人员的体验来对比回答什么时候使用RabbitMQ或Apache Kafka问题。

4.1 起源

RabbitMQ 是一个“传统”消息代理，能够实现各类消息传递协议。它是首批实现合理级别功能，客户端库，开发工具和质量文档的开源消息代理之一。RabbitMQ最初是为实现AMQP而开发的，AMQP是一种开放式线路协议，具备强大的路由功能。虽然Java具备像JMS这样的消息传递标准，但它对于须要分布式消息传递的非Java应用程序没有帮助，由于它严重限制了任何集成场景，微服务或单片机。随着AMQP的出现，跨语言的灵活性成为开源消息代理的真实存在。

Apache Kafka 是在Scala中开发的，最初是在LinkedIn（领英）上做为链接不一样内部系统的一种方式。当时，LinkedIn正在转向更加分散的架构，须要从新构想数据集成和实时流处理等功能，从而摆脱之前单一的方法来解决这些问题。今天，Kafka在Apache Software Foundation产品生态系统中获得了很好的采用，在事件驱动的架构中特别有用。

4.2 架构设计

RabbitMQ

RabbitMQ被设计为通用消息代理，采用点对点，request(请求)//reply(回复)和pub-sub通讯样式模式的多种变体。
它使用智能 broker(代理)/dumb(哑) 消费者模型，专一于向消费者提供一致的消息传递，消费者的消费速度与经纪人跟踪消费者状态的速度大体类似。
它是成熟的，在正确配置时表现良好，获得很好的支持（客户端库Java，.NET，node.js，Ruby，PHP和更多语言），而且有许多可用的插件能够将它扩展到更多的用例和集成场景。

简化总体RabbitMQ架构资料来源：http://kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

RabbitMQ中的通讯能够根据须要同步或异步。发布者向交换发送消息，消费者从队列中检索消息。经过交换将生产者与队列分离可确保生产者不会受到硬编码路由决策的影响。RabbitMQ还提供了许多分布式部署方案（而且确实要求全部节点都可以解析主机名）。能够将多节点群集设置为群集联合，而且不依赖于外部服务（但某些群集造成插件可使用AWS API，DNS，Consul等）。

Apache KafKa

Apache Kafka专为高容量发布 - 订阅消息和流而设计，旨在持久，快速和可扩展。

从本质上讲，Kafka提供了一个持久的消息存储，相似于日志，在服务器集群中运行，它存储称为主题的类别中的记录流。

Figure 2 - Global Apache Kafka architecture (with 1 topic, 1 partition, replication factor 4). 资料来源：http://kth.diva-portal.org/smash/get/diva2:813137/FULLTEXT01.pdf

每条消息都包含一个键，一个值和一个时间戳。几乎与RabbitMQ相反，Kafka雇用了一个笨重的经纪人，并使用聪明的消费者来读取它的缓冲区。Kafka不会尝试跟踪每一个消费者读取的消息，只保留未读消息; 相反，Kafka会在一段时间内保留全部消息，消费者有责任在每一个日志（消费者状态）中跟踪他们的位置。所以，经过合适的开发人员建立消费者代码，Kafka能够支持大量消费者并以极少的开销保留大量数据。如上图所示，Kafka确实须要运行外部服务 - 在这种状况下是Apache Zookeeper，这一般被认为是很是容易理解，设置和操做的。

Requirements and Use Cases 要求和用例

Apache Kafka

许多开发人员在乎识到必须将大量内容链接在一块儿时开始探索消息传递，而其余集成模式（如共享数据库）则不可行或太危险。

Apache Kafka包括代理自己，它其实是最着名和最受欢迎的部分，而且已经设计并突出地推向流处理场景。除此以外，Apache Kafka最近还添加了Kafka Streams，它将本身定位为Apache Spark，Apache Flink，Apache Beam / Google Cloud Data Flow和Spring Cloud Data Flow等流媒体平台的替代品。该文档很好地讨论了网站活动跟踪，度量标准，日志聚合，流处理，事件采购和提交日志等常见用例。它描述的其中一个用例是消息传递，它可能会产生一些混乱。所以，让咱们解决一下，并清楚了解哪些消息传递方案最适合Kafka，例如：

从A到B流，没有复杂的路由，最大吞吐量（100k / sec +），按分区顺序至少提交一次。
当您的应用程序须要访问流历史记录时，至少按分区顺序提供一次。Kafka是一个持久的消息存储，客户能够根据须要“重播”事件流，而不是更传统的消息代理，一旦消息传递，它就会从队列中删除。
流处理
活动采购

RabbitMQ

RabbitMQ是一种通用消息传递解决方案，一般用于容许Web服务器快速响应请求，而不是在用户等待结果时强制执行资源繁重的过程。它还能够将消息分发给多个接收者以供消费，或者在高负载（20k + / sec）下平衡负载之间的负载。当您的需求超出吞吐量时，RabbitMQ可提供许多功能：可靠的交付，路由，联合，HA，安全性，管理工具和其余功能。让咱们来看看RabbitMQ的最佳场景，例如：

您的应用程序须要使用现有协议的任意组合，如AMQP 0-9-1，STOMP，MQTT，AMQP 1.0。
您须要基于每一个消息（死信队列等）进行更精细的一致性控制/保证。可是，Kafka最近添加了更好的事务支持。
您的应用程序须要点对点，请求/回复以及发布/订阅消息传递的多样性
复杂的路由到消费者，使用非平凡的路由逻辑集成多个服务/应用程序

RabbitMQ还能够有效地解决上面几个Kafka强大的用例，可是在其余软件的帮助下。当应用程序须要访问流历史时，RabbitMQ一般与Apache Cassandra一块儿使用，对于须要“无限”队列的应用程序，RabbitMQ一般与LevelDB插件一块儿使用，但这两种功能都不附带RabbitMQ自己。

为了更深刻地了解Kafka和RabbitMQ的微服务特定用例，请访问Pivotal博客并阅读Fred Melo的这篇简短帖子。

开发经验

RabbitMQ

RabbitMQ正式支持Java，Spring，.NET，PHP，Python，Ruby，JavaScript，Go，Elixir，Objective-C，Swift - 经过社区插件与许多其余客户端和devtools一块儿支持。RabbitMQ客户端库已经成熟而且文档齐全。

Apache Kafaka

Apache Kafka在这方面取得了长足进步，虽然它只提供了一个Java客户端，可是社区开源客户端，生态系统项目以及适配器SDK的目录不断增长，能够构建本身的系统集成。大部分配置是经过.properties文件或以编程方式完成的。

这两个选项的普及对许多其余软件提供商产生了很大的影响，这些软件提供商确保RabbitMQ和Kafka在他们的技术上运行良好。

至于开发人员的体验...值得一提的是咱们在Spring Kafka，Spring Cloud Stream等中提供的支持。

安全和运营

RabbitMQ

二者都是RabbitMQ的优点。RabbitMQ管理插件提供HTTP API，基于浏览器的管理和监控UI，以及运营商的CLI工具。长期监控数据存储须要使用CollectD，Datadog或New Relic等外部工具。RabbitMQ还提供用于监控，审计和应用程序故障排除的API和工具。除了支持TLS以外，RabbitMQ还附带了由内置数据存储，LDAP或基于HTTPS的外部提供程序支持的RBAC，并支持使用x509证书而不是用户名/密码对进行身份验证。使用插件能够至关简单地开发其余身份验证方法。

Kafaka

这些领域对Apache Kafka构成了挑战。在安全方面，最近的Kafka 0.9版本添加了TLS，基于JAAS角色的访问控制和kerberos / plain / scram auth，使用CLI管理安全策略。这对早期版本进行了实质性改进，您只能锁定网络级别的访问权限，这对于共享或多租户来讲效果不佳。

Kafka使用由shell脚本，属性文件和特定格式的JSON文件组成的管理CLI。Kafka Brokers，生产商和消费者经过Yammer / JMX发布指标，但没有保留任何历史记录，这实际上意味着使用第三方监控系统。使用这些工具，操做能够管理分区和主题，检查消费者偏移位置，并使用Apache Zookeeper为Kafka提供的HA和FT功能。虽然许多人认为对Zookeeper的要求存在高度怀疑，但它确实为Kafka用户带来了集群优点。

例如，3节点Kafka集群即便在2次故障后系统也能正常运行。可是，若是要在Zookeeper中支持尽量多的故障，则须要额外的5个Zookeeper节点，由于Zookeeper是基于仲裁的系统，而且只能容忍N / 2 + 1故障。这些显然不该该与Kafka节点共存 - 因此要创建一个3节点的Kafka系统，你须要~8台服务器。在推断任何Kafka系统的可用性时，运营商必须考虑ZK集群的属性，不管是在资源消耗仍是设计方面。

性能

Kafka

Kafka在设计上大放异彩：100k / sec的性能一般是人们选择Apache Kafka的关键驱动因素。

固然，每秒消息的速率很难说明和量化，由于它们依赖于不少，包括你的环境和硬件，你的工做负载的性质，使用的交付保证（例如持久性成本高，镜像甚至更多）等等。

RabbitMQ

每秒20K消息很容易经过单个Rabbit队列推送，实际上并不比这更难，对保证方式的要求不高。该队列由一个Erlang轻量级线程支持，该线程在本机操做系统线程池上进行协做调度 - 所以它成为一个天然的瓶颈或瓶颈，由于单个队列永远不会作更多的工做，而不是让CPU周期工做在。

每秒增长消息一般归结为经过巧妙的路由（例如，能够同时运行不一样的队列）来执行诸如跨多个队列中断流量之类的事情来正确利用一个环境中可用的并行性。当RabbitMQ 每秒实现100万条消息时，这个用例基本上彻底是为了明智地作到这一点 - 可是使用了大量资源，大约30个RabbitMQ节点实现了。大多数RabbitMQ用户都享有卓越的性能，集群由3到7个RabbitMQ节点组成。

0x05 什么是RabbitMQ?

RabbitMQ 官网：http://www.rabbitmq.com/

RabbitMQ是部署最普遍的开源消息代理。

RabbitMQ在全球范围内在小型初创公司和大型企业进行了超过35,000次的生产部署，是最受欢迎的开源消息代理。

RabbitMQ轻巧且易于部署在云端和云端。它支持多种消息传递协议。 RabbitMQ能够部署在分布式和联合配置中，以知足高规模，高可用性需求。

RabbitMQ可运行在许多操做系统和云环境中，并为大多数流行语言提供普遍的开发工具。

————官网解释

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。

RabbitMQ服务器是用Erlang语言编写的，而群集和故障转移是构建在开放电信平台框架上的。

———— 维基百科

Tips:

在最近研读的Think in Java 第四版中有这样一段话：

若是你发现程序中某个部分必须大量使用并发，而且你在试图构建这个部分时碰到了过多的问题，那么你能够考虑使用Erlang 这类专门的并发语言来建立这个部分。

本篇完~

更多请看个人RabbitMQ 学习专栏：http://www.javashuo.com/article/p-qqwuyhfr-mq.html