RabbitMQ Tutorials

(5) 因为交换器是命名实体，声明一个已经存在的交换器，但是试图赋予不同类型是会导致错 误。客户端需要删除这个已经存在的交换器，然后重新声明并且赋予新的类型。
(6) 交换器的属性： - 持久性：如果启用，交换器将会在server重启前都有效。 - 自动删除：如果启用，那么交换器将会在其绑定的队列都被删除掉之后自动删除掉自身。 - 惰性：如果没有声明交换器，那么在执行到使用的时候会导致异常，并不会主动声明。
基本示意图
虚拟主机（virtual host）
一个虚拟主机持有一组交换机、队列和绑定。为什么需要多个虚拟主机呢？很简单，
RabbitMQ当中，用户只能在虚拟主机的粒度进行权限控制。因此，如果需要禁止A组访问B组 的交换机/队列/绑定，必须为A和B分别创 建一个虚拟主机。每一个RabbitMQ服务器都有一个 默认的虚拟主机“/”。
选择RabbitMQ一个重要原因就是消息的持久化。
RabbitMQ简介
AMQP，即Advanced Message Queuing Protocol，高级消息队列协议， 是应用层协议的一个开放标准，为面向消息的中间件设计。
消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者 的存在，反之亦然。
Producer 要产生消息必须要创建一个 Exchange ，Exchange 用于转发消息，但是它不会 做存储，如果没有 Queue bind 到 Exchange 的话，它会直接丢弃掉 Producer 发送过来的消 息，当然如果消息总是发送过去就被直接丢弃那就没有什么意思了，一个 Consumer 想要接受 消息的话，就要创建一个 Queue ，并把这个 Queue bind 到指定的 Exchange 上，然后 Exchange 会把消息转发到 Queue 那里，Queue 会负责存储消息，Consumer 可以通过主动 P从 Queue 中取得消息。
消息传递
(1) 消息在队列中保存，以轮询的方式将消息发送给监听消息队列的消费者，可以动态的增加 消费者以提高消息的处理能力。
(2) 为了实现负载均衡，可以在消费者端通知RabbitMQ，一个消息处理完之后才会接受下一个 消息。
channel.basic_qos(prefetch_count=1) 注意：要防止如果所有的消费者都在处理中，则队列中的消息会累积的情况。
(3) 队列的属性： - 持久性：如果启用，队列将会在server重启前都有效。 - 自动删除：如果启用，那么队列将会在所有的消费者停止使用之后自动删除掉自身。 - 惰性：如果没有声明队列，那么在执行到使用的时候会导致异常，并不会主动声明。 - 排他性：如果启用，队列只能被声明它的消费者使用。 这些性质可以用来创建例如排他和自删除的transient或者私有队列。这种队列将会在所有链接 到它的客户端断开连接之后被自动删除掉。它们只是短暂地连接到server，但是可以用于实现 例如RPC或者在AMQ上的对等通信。(关于rpc没进行研究，后面说明原因)
关于RPC
A note on RPC Although RPC is a pretty common pattern in computing, it's often criticised. The problems arise when a programmer is not aware whether a function call is local or if it's a slow RPC. Confusions like that result in an unpredictable system and adds unnecessary complexity to debugging. Instead of simplifying software, misused RPC can result in unmaintainable spaghetti code.
简单来说就是使用RPC增加了不确定，以及增加调试的复杂度。官网的思想是简化你的软件， 滥用RPC可能会造成很多错误。所以没去研究rpc。 研究rpc可以去官网看看例子，反正我是没看 /tutorials/tutorial-six-python.html
Message acknowledgment：
当“Consumer”接受到一个消息并作长时间处理时，有可能发生意外状况，如运行 “Consumer”的机器突然关闭，这时这个消息所要执行的任务可能没有得到正确处理。
RabittMQ Tutorials
占涛
引言
你是否遇到过两个（多个）系统间需要通过定时任务来同步某些数据？你 是否在为异构系统的不同进程间相互调用、通讯的问题而苦恼、挣扎？ 如果是，那么恭喜你，消息服务让你可以很轻松地解决这些问题。
消息服务擅长于解决多系统、异构系统间的数据交换（消息通知/通讯） 问题，你也可以把它用于系统间服务的相互调用（RPC）。 本文将要介绍的RabbitMQ就是当前最主流的消息中间件之一。
(3) 消息有14个属性，最常用的几种： deliveryMode：持久化属性 contentType：编码 replyTo：指定一个回调队列 correlationId：消息id (4) 消息生产者可以选择是否在消息被发送到交换器并且还未投递到队列（没有绑定器存在） 和/或没有消费者能够立即处理的时候得到通知。通过设置消息的mandatory和/或immediate属 性为真，这些投递保障机制的能力得到了强化。
集群（cluster）：
(1) 不支持跨网段（如需支持，需要shovel或federation插件） (2) 可以随意的动态增加或减少、启动或停止节点，允许节点故障 (3) 集群分为RAM节点和DISK节点，一个集群最好至少有一个DISK节点保存集群的状态。 (4) 集群的配置可以通过命令行，也可以通过配置文件，命令行优先。
交换机（Exchang）
(1) 接收消息，转发消息到绑定的队列。四种类型：direct, topic, headers and fanout direct：转发消息到routigKey指定的队列 topic：按规则转发消息（最灵活） headers：（较为少用） fanout：转发消息到所有绑定队列 (2) 如果没有队列绑定在交换机上，则发送到该交换机上的消息会丢失。交换机不做消息存储。 (3) 一个交换机可以绑定多个队列，一个队列可以被多个交换机绑定。 (4) topic类型交换器通过模式匹配分析消息的routing-key属性。它将routing-key和binding-key 的字符串切分成单词。这些单词之间用点隔开。它同样也会识别两个通配符：#匹配0个或者多 个单词，*匹配一个单词。例如，binding key：*.stock.#匹配routing key：usd.stcok和 eur.stock.db，但是不匹配stock.nana。 还有一些其他的交换器类型，如header、failover、system等，现在在当前的RabbitMQ版本中 均未实现。
(5) 此外，一个生产者可以设置消息的persistent属性为真。这样一来，server将会尝试将这些 消息存储在一个稳定的位置，直到server崩溃。当然，这些消息肯定不会被投递到非持久的队 列中。
高可用性（HA）
(1) 消息ACK，通知RabbitMQ消息已被处理，可以从内存删除。如果消费者因宕机或链接失败 等原因没有发送ACK（不同于ActiveMQ，在RabbitMQ里，消息没有过期的概念），则 RabbitMQ会将消息重新发送给其他监听在队列的下一个消费者。
AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、 可靠性、安全。
RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持 多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、 ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发 消息，在易用性、扩展性、高可用性等方面表现不俗。 下面将重点介绍RabbitMQ中的一些基础概念，了解了这些概念，是使用好 RabbitMQ的基础。
channel.basicPublish(exchangeName, routingKey,
MessageProperties.PERSISTENT_TEXT_PLAIN,
message.getBytes()); 这样，即使RabbitMQ服务器重启，也不会丢失队列和消息。
(3) publisher confirms (4) master/slave机制，配合Mirrored Queue，这种情况下，publisher会正常发送消息和接收消 息的confirm，但对于subscriber来说，需要接收Consumer Cancellation Notifications来得到主 节点失败的通知，然后re-consume from the queue，此时要求client有处理重复消息的能力。 注意：如果queue在一个新加入的节点上增加了一个slave，此时slave上没有此前queue的信息 （目前还没有同步机制）。 （通过命令行或管理插件可以查看哪个slave是同步的： rabbitmqctl list_queues name slave_pids synchronised_slave_pids） 当一个slave重新加入mirrored-queue时，如果queue是durable的，则会被清空。
队列（Queues）
是你的消息（messages）的终点，可以理解成装消息的容器。消息就一直在里面，直到 有客户端（也就是消费者，Consumer）连接到这个队列并且将其取走为止。
需要记住的是，队列是由消费者（Consumer）通过程序建立的，不是通过配置文件或者 命令行工具。这没什么问题，如果一个消费者试图创建一个已经存在的队列，RabbitMQ会忽 略这个请求。因此你可以将消息队列的配置写在应用程序的代码里面。这个概念不错。