RabbitMQ essentials

hop straight into developing your own messaging applications by learning how to utilize RabbitMQ

阅读自RabbitMQ Essentials。 RabbitMQ是开源消息经纪人实现AMQP 协议。

第一章A rabbit springs to life

消息和消息队列是应用和组成部分交互的一种方式，允许一个松弛耦合的系统。Advanced Message Queuing Protocol(AMQP)是一个标准定义彼此写作的消息协议的语义学。RabbitMQ是一个Erlang语言实现的AMQP，支持高级功能比如clustering。

Meet AMQP

AMQP是开放标准定义系统间交换消息的协议。AMPQ不仅只定义consumer/producer 和broker的交互,也定义了电报上消息的代表和被交换的命令。由于它精确了消息的报文格式，AMQP是真实的互相协作的——没有什么是留给一个供货商或主机平台解释。由于它也是开放的，AMQP社区繁荣，有多重broker,client的实现在不同语言中。
AMQP的核心概念：

• Broker:这是中间应用件能收到消息由publisher产生，发送它们到consumers或者其它的broker。
• Virtual host:这是在broker的虚拟部门允许publisher,consumer,所有它们依赖构建的AMQP的分离，通常由于安全的原因。
• Connetcion：这是一个物理网络(TCP)连接在一个publisher/consumer和一个broker间。这连接只在客户连接断了或network/broker failure。
• Channer:这是一个逻辑链接在一个publisher/consumer 和broker之间。多个管道可以被建立在一个单独连接中。Channels允许一个特定client和broker的交互的隔离这样它们不会互相干扰。这不需要打开昂贵的单独的TCP链接。一个channel能关闭当一个protocol错误发生。
• Exchange：这是目的地对于所有发布的消息，实体负责应用转发规则对于这些消息让它们到达它们的目的地。routing规则包括直接（点对点）、topic（发布-订阅）、fanout（多播）。
• 队列：这是要被消费的消息的最终目的。一个单独的消息能被复制能达到多个队列如果exchange的规则需要如此。
• 绑定：这是一个exchange和queue的虚拟连接，允许消息从exchange流到queue。一个路由规则key能和一个binding关联和exchange路由规则相关。

AMQP和其它协议的区别主要在什么地方，以下是主要特征的一些比较：

• Java Message Servie(JMS):这只定义了protocol对于Java变成不是消息。
• MQ Telemetry Transport(MQTT):这是极度轻量级的消息-队列协议。MQTT着眼于publish-subscribe模型。不像AMQP，这是互相协作的很适合于大规模部署在嵌入系统中。和AMQP类似，依赖于broker用于订阅管理和消息路由。RabbitMQ能speak MQTT协议。
• ZeroMQ：提供消息语义学不需要中心broker（没有一致性和分发保证一个broker能提供的）。核心，它是一个写作的网络库。在很多语言实现，它是一个选择工具用于构建高性能和高可提供的分布式系统。
• Process inbox:Erlang或Akka提供消息语法。它们依赖于clustering技术来分布消息在process和actors之间。由于它们是嵌入在主机应用的，它们捕食设计用于互相协作的。

多个商业和开源的AMQP的实现可获得。经常，存在的messaging broker被扩展用一个AMQP adapter,比如ActiveMQ的例子。
这本书中我们会详细研究开源broker。

The RabbitMQ broker

RabbitMQ是Erlang实现的AMQP。Erlang被选择因为它内在的本质支持构建高可靠性和分布式应用。Erlang可以运行在任何操作系统上。
RabbitMQ实现了AMQP的0-9-1版本，有一些自定义扩展和一些RabbitMQ想要保存的功能。对于数据一致性，它依赖于Mnesia，在内存中/文件一致性Erlang的嵌入数据库，和明确的消息存储和索引文件。对于clustering，主要依赖于Erlang根深蒂固的clustering能力。RabbitMQ能很容易被扩展，比如，一个web-based管理控制台能在其上部署。

RabbitMQ不仅能cluster一起，也能连接用不同技术，比如federations或shovels，为了形成消息拓扑有智能消息转发在不同broker间，能够扩展到多个数据中心。

AMQP1.0发布于2011，开发和维护AMQP被转移给OASIS。AMQP 0-9-1版本和1.0相差很大。一些核心概念，比如exchange不再存在。有人争论说它失去了一些关键吸引人的方面。

A case for RabbitMQ

Clever Coney Media(CCM)是一个虚假的集成软件和数字媒体代理公司制定开发应用用于在线社区。它们软件全局，是各种技术的混杂。

• 旗帜性产品是Rich Internet Application(RIA)，Java后端。终端用户参与主题的在线社区。
• 灰色盒子用Ruby on Rails构建。
• 公司网站和博客用PHP运行。
• 一个ad hoc python脚本用来抽取消息数据为了产生使用报告。

第二章 Creating an Application Inbox

Application需要用RabbitMQ需要建立一个永久连接到它。当连接建立，逻辑channel能被建立，面向消息的交互，比如publishing,获取消息能被执行。学习这些基础后，你会学习如何exchange-routing策略决定消息如何发送到队列。特别地，你会学习到直接交换，发送消息到一个单独队列，和topic exchang，发送消息到多个队列基于pattern-matching routing keys。 这一章，会讨论：

• 建立一个实体连接到RabbitMQ
• 与channel工作
• 发布消息到RabbitMQ
• 从RabbitMQ收取消息
• 直接和topic 交换

Connecting to RabbitMQ

需要建立一个物理连接在应用服务器和RabbitMQ间，会被很多逻辑channel使用。不同于创建channel，创建connection是一个昂贵的操作，和数据库连接很相像。通常来说，数据库连接是pooled，pool的每个实例被一个单独执行线程所使用。AMQP不同，一个单独链接呗很多线程使用通过很多多工channels。因此，建立一个单独的长久存在的链接在应用服务器和RabbitMQ应该是足够支持新功能，知道被证明是饱和的需要多个连接是必须的。

CCM的行为需要遵守以下几点：

• 应用应该开始无论到RabbitMQ的连接是否建立或没有
• 如果到RabbitMQ的连接丢失了，需要自动连接
• 如果连接断了，发送或获取消息应该优雅地失败

第三章 Switching to Server-push

message能被push到consumer。在这个过程，会学习到如何消息消费者手动确定消息或者接收到消息不需要确认，前者允许一个零消息丢失设计。最后，你会熟悉fanout exchange,转发消息到所有队列绑定至它的，不管routing keys。
会学习一下主题：

• 从队列consume消息
• 手动确定消息
• fanout exchange

Moving beyond polling

CCM决定用server-push方法重新设计整个体系。WebSocket技术可用于这个需求。这个协议是full-duplex,消息可以流向两个方向。CCM会保持AJAX 终端点为了支持老版本的浏览器。 注册一个listener新的消息到达队列会自动分发。

第四章 Handing Application Logs

RabbitMQ能用于应用log处理。将要学习转发logs在应用发布它们，自定义脚本处理它们。学习以下主题：

• log的集中化用RabbitMQ
• JMeter的加载测试
• 服务和消息预获取的channel质量
• 路由键模式

其余部分都是具体代码，不想看了。如果在ms内网，可以访问这个继续阅读。