From：http://blog.csdn.net/whycold/article/details/41119807
From： http://blog.csdn.net/cugb1004101218/article/details/21243927
参考：https://www.host900.com/index.php/articles/351/
参考：http://similarface.blog.51cto.com/3567714/1872614
参考：http://www.cnblogs.com/shanyou/p/4067250.html
.Net使用RabbitMQ详解：http://www.cnblogs.com/knowledgesea/p/5296008.html
RabbitMQ 官网：http://www.rabbitmq.com/
RabbitMQ 英文文档：http://www.rabbitmq.com/documentation.html
RabbitMQ 中文文档：http://rabbitmq.mr-ping.com/description.html
RabbitMQ基础概念详细介绍
引言
你是否遇到过两个（多个）系统间需要通过定时任务来同步某些数据？你是否在为异构系统的不同进程间相互调用、通讯的问题而苦恼、挣扎？如果是，那么恭喜你，消息服务让你可以很轻松地解决这些问题。消息服务擅长于解决多系统、异构系统间的数据交换（消息通知/通讯）问题，你也可以把它用于系统间服务的相互调用（RPC）。本文将要介绍的RabbitMQ就是当前最主流的消息中间件之一。
AMQP协议
介绍RabbitMQ前，先了解一下AMQP协议。AMQP协议(Advanced Message Queuing Protocol (AMQP))是一个高级抽象层消息通信协议，RabbitMQ是AMQP协议的实现。它主要包括以下组件 ( 四个重要概念：虚拟主机（virtual host），交换机（exchange），队列（queue）和绑定（binding）)：
- Server(broker)：
接受客户端连接，实现AMQP消息队列和路由功能的进程。 - Virtual Host：虚拟主机
其实是一个虚拟概念，类似于权限控制组，一个Virtual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Virtual Host。一个虚拟主机持有一组交换机、队列和绑定。为什么需要多个虚拟主机呢？RabbitMQ当中，用户只能在虚拟主机的粒度进行权限控制。因此，如果需要禁止A组访问B组的交换机/队列/绑定，必须为A和B分别创建一个虚拟主机。每一个RabbitMQ服务器都有一个默认的虚拟主机“/”。 - Exchange：交换机
接受生产者发送的消息，并根据Binding规则将消息路由给服务器中的队列。ExchangeType决定了Exchange路由消息的行为。
也可以理解成具有路由表的路由程序。每个消息都有一个路由键（routing key），就是一个简单的字符串。交换机中有一系列的绑定（binding），即路由规则（routes）。交换机可以有多个。多个队列可以和同一个交换机绑定，同时多个交换机也可以和同一个队列绑定。（多对多的关系）。例如，在RabbitMQ中，ExchangeType有direct、Fanout和Topic三种，不同类型的Exchange路由的行为是不一样的。
三种交换机：
1. Fanout
Exchange（不处理路由键）：一个发送到交换机上的消息都会被转发到与该交换机绑定的所有队列上。Fanout交换机发消息是最快的。
2. Direct
Exchange（处理路由键）：如果一个队列绑定到该交换机上，并且当前要求路由键为X，只有路由键是X的消息才会被这个队列转发。
3. Topic
Exchange（将路由键和某模式进行匹配，可以理解成模糊处理）：路由键的词由“.”隔开，符号“#”表示匹配0个或多个词，符号“*”表示匹配不多不少一个词。因此“audit.#”能够匹配到“audit.irs.corporate”，但是“audit.*”只会匹配到“audit.irs” - Message Queue：消息队列。
用于存储还未被消费者消费的消息。 Message：消息
由Header和Body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受、优 先级是多少等。而Body是真正需要传输的APP数据。Binding：绑定
Binding联系了Exchange与Message Queue。Exchange在与多个Message Queue发生Binding后会生成一张路由表，路由表中存储着Message Queue所需消息的限制条件即Binding Key。当Exchange收到Message时会解析其Header得到Routing Key，Exchange根据Routing Key与Exchange Type将Message路由到Message Queue。Binding Key由Consumer在Binding Exchange与Message Queue时指定，而Routing Key由Producer发送Message时指定，两者的匹配方式由Exchange Type决定。Connection：连接。
对于RabbitMQ而言，其实就是一个位于客户端和Broker之间的TCP连接。Channel：信道。
仅仅创建了客户端到Broker之间的连接后，客户端还是不能发送消息的。需要为每一个Connection创建Channel，AMQP协议规定只有通过Channel才能执行AMQP的命令。一个Connection可以包含多个Channel。之所以需要Channel，是因为TCP连接的建立和释放都是十分昂贵的，如果一个客户端每一个线程都需要与Broker交互，如果每一个线程都建立一个TCP连接，暂且不考虑TCP连接是否浪费，就算操作系统也无法承受每秒建立如此多的TCP连接。RabbitMQ建议客户端线程之间不要共用Channel，至少要保证共用Channel的线程发送消息必须是串行的，但是建议尽量共用Connection。Command：AMQP 的命令。
客户端通过Command完成与AMQP服务器的交互来实现自身的逻辑。例如在RabbitMQ中，客户端可以通过publish命令发送消息，txSelect开启一个事务，txCommit提交一个事务。
在了解了AMQP模型以后，需要简单介绍一下AMQP的协议栈，AMQP协议本身包括三层：
- Modle Layer
位于协议最高层，主要定义了一些供客户端调用的命令，客户端可以利用这些命令实现自己的业务逻辑。即 规范服务器端Broker的行为。
例如，客户端可以通过queue.declare声明一个队列，利用consume命令获取一个队列中的消息。 - Session Layer
主要负责将客户端的命令发送给服务器，在将服务器端的应答返回给客户端，主要为客户端与服务器之间通信提供可靠性、同步机制和错误处理。即 定义客户端与服务器端Broker的Context。 - Transport Layer
主要传输二进制数据流，提供帧的处理、信道复用、错误检测和数据表示。
从AMQP协议可以看出，MessageQueue、Exchange 和 Binding 构成了AMQP协议的核心。
模型：AMQP服务器Broker主要由Exchange和Message Queue组成，主要功能是Message的路由Routing和缓存Buffering。
Exchange接受Producer发送的Message并根据不同路由算法将Message发送到Message Queue。
Message Queue会在Message不能被正常消费时将其缓存起来，但是当Consumer与Message Queue之间的连接通畅时，Message Queue将Message转发给Consumer。
Message由Header和Body组成，Header是由Producer添加的各种属性的集合，包括Message是否客被缓存、由哪个Message Queue接受、优先级是多少等。而Body是真正需要传输的APP数据。
Exchange与Message Queue之间的关联通过Binding来实现。Exchange在与多个Message Queue发生Binding后会生成一张路由表，路由表中存储着Message Queue所需消息的限制条件即Binding Key。当Exchange收到Message时会解析其Header得到Routing Key，Exchange根据Routing Key与Exchange Type将Message路由到Message Queue，流程如下图：
Binding Key由Consumer在Binding Exchange与Message Queue时指定，而Routing Key由Producer发送Message时指定，两者的匹配方式由Exchange Type决定。
Exchange Type分为Direct（单播）、Topic（组播）、Fanout（广播）。当为Direct（单播）时，Routing Key必须与Binding Key相等时才能匹配成功，当为Topic（组播）时，Routing Key与Binding Key符合一种模式关系即算匹配成功，当为Fanout（广播）时，不受限制。默认Exchange Type是Direct（单播）。
Virtual Host是个虚拟概念，可以持有一些Exchange和Message Queue。一个Virtual Host可以是一台服务器，也可以是由多台服务器组成的集群。Exchange和Message Queue可以分别部署在一台或者多台服务器上。
通信
在AMQP中，Client通过与Broker之间建立Connection来通信，而Connection建立在Client与Virtual Host之间。而在每个Connection上可以运行多个Channel，每个Channel执行与Broker的通信，Session依附于Channel之上。Channel是Client与Broker之间传输Message的实体。在通信的时候，会为每个Command分配一个唯一的标示符即UUID，用于Command做校验和重传。
Client默认使用guest/guest访问权限和访问虚拟主机的根目录，这些默认项也是RabbitMQ的默认安装选项。
RabbitMQ简介
AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。
AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。
下面将重点介绍RabbitMQ中的一些基础概念，了解了这些概念，是使用好RabbitMQ的基础。
RabbitMQ基础概念
ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的socket链接，它封装了socket协议相关部分逻辑。ConnectionFactory为Connection的制造工厂。
Channel是我们与RabbitMQ打交道的最重要的一个接口，我们大部分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。
Queue
Queue（队列）是RabbitMQ的内部对象，用于存储消息，用下图表示。
RabbitMQ中的消息都只能存储在Queue中，生产者（下图中的P）生产消息并最终投递到Queue中，消费者（下图中的C）可以从Queue中获取消息并消费。
多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
Message acknowledgment
在实际应用中，可能会发生消费者收到Queue中的消息，但没有处理完成就宕机（或出现其他意外）的情况，这种情况下就可能会导致消息丢失。为了避免这种情况发生，我们可以要求消费者在消费完消息后发送一个回执给RabbitMQ，RabbitMQ收到消息回执（Message acknowledgment）后才将该消息从Queue中移除；如果RabbitMQ没有收到回执并检测到消费者的RabbitMQ连接断开，则RabbitMQ会将该消息发送给其他消费者（如果存在多个消费者）进行处理。这里不存在timeout概念，一个消费者处理消息时间再长也不会导致该消息被发送给其他消费者，除非它的RabbitMQ连接断开。
这里会产生另外一个问题，如果我们的开发人员在处理完业务逻辑后，忘记发送回执给RabbitMQ，这将会导致严重的bug——Queue中堆积的消息会越来越多；消费者重启后会重复消费这些消息并重复执行业务逻辑…
另外pub message是没有ack的。
Message durability
如果我们希望即使在RabbitMQ服务重启的情况下，也不会丢失消息，我们可以将Queue与Message都设置为可持久化的（durable），这样可以保证绝大部分情况下我们的RabbitMQ消息不会丢失。但依然解决不了小概率丢失事件的发生（比如RabbitMQ服务器已经接收到生产者的消息，但还没来得及持久化该消息时RabbitMQ服务器就断电了），如果我们需要对这种小概率事件也要管理起来，那么我们要用到事务。由于这里仅为RabbitMQ的简单介绍，所以这里将不讲解RabbitMQ相关的事务。
Prefetch count
前面我们讲到如果有多个消费者同时订阅同一个Queue中的消息，Queue中的消息会被平摊给多个消费者。这时如果每个消息的处理时间不同，就有可能会导致某些消费者一直在忙，而另外一些消费者很快就处理完手头工作并一直空闲的情况。我们可以通过设置prefetchCount来限制Queue每次发送给每个消费者的消息数，比如我们设置prefetchCount=1，则Queue每次给每个消费者发送一条消息；消费者处理完这条消息后Queue会再给该消费者发送一条消息。
Exchange
在上一节我们看到生产者将消息投递到Queue中，实际上这在RabbitMQ中这种事情永远都不会发生。实际的情况是，生产者将消息发送到Exchange（交换器，下图中的X），由Exchange将消息路由到一个或多个Queue中（或者丢弃）。
Exchange是按照什么逻辑将消息路由到Queue的？这个将在Binding一节介绍。
RabbitMQ中的Exchange有四种类型，不同的类型有着不同的路由策略，这将在Exchange Types一节介绍。
routing key
生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则，而这个routing key需要与Exchange Type及binding key联合使用才能最终生效。
在Exchange Type与binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定routing key来决定消息流向哪里。
RabbitMQ为routing key设定的长度限制为255 bytes。
Binding
RabbitMQ中通过Binding将Exchange与Queue关联起来，这样RabbitMQ就知道如何正确地将消息路由到指定的Queue了。
Binding key
在绑定（Binding）Exchange与Queue的同时，一般会指定一个binding key；消费者将消息发送给Exchange时，一般会指定一个routing key；当binding key与routing key相匹配时，消息将会被路由到对应的Queue中。这个将在Exchange Types章节会列举实际的例子加以说明。
在绑定多个Queue到同一个Exchange的时候，这些Binding允许使用相同的binding key。
binding key 并不是在所有情况下都生效，它依赖于Exchange Type，比如fanout类型的Exchange就会无视binding key，而是将消息路由到所有绑定到该Exchange的Queue。
Exchange Types
RabbitMQ常用的Exchange Type有fanout、direct、topic、headers这四种（AMQP规范里还提到两种Exchange Type，分别为system与自定义，这里不予以描述），下面分别进行介绍。
fanout
fanout类型的Exchange路由规则非常简单，它会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中。
上图中，生产者（P）发送到Exchange（X）的所有消息都会路由到图中的两个Queue，并最终被两个消费者（C1与C2）消费。
direct
direct类型的Exchange路由规则也很简单，它会把消息路由到那些binding key与routing key完全匹配的Queue中。
以上图的配置为例，我们以routingKey=”error”发送消息到Exchange，则消息会路由到Queue1（amqp.gen-S9b…，这是由RabbitMQ自动生成的Queue名称）和Queue2（amqp.gen-Agl…）；如果我们以routingKey=”info”或routingKey=”warning”来发送消息，则消息只会路由到Queue2。如果我们以其他routingKey发送消息，则消息不会路由到这两个Queue中。
topic
前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但这里的匹配规则有些不同，它约定：
- routing key为一个句点号“. ”分隔的字符串（我们将被句点号“. ”分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
- binding key与routing key一样也是句点号“. ”分隔的字符串
- binding key中可以存在两种特殊字符“*”与“#”，用于做模糊匹配，其中“*”用于匹配一个单词，“#”用于匹配多个单词（可以是零个）
以上图中的配置为例，routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的消息会路由到Q1与Q2，routingKey=”lazy.brown.fox”的消息会路由到Q2，routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。
headers
headers类型的Exchange不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。
在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对；如果完全匹配则消息会路由到该Queue，否则不会路由到该Queue。
该类型的Exchange没有用到过（不过也应该很有用武之地），所以不做介绍。
RPC
MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。
但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC。
RabbitMQ中实现RPC的机制是：
- 客户端发送请求（消息）时，在消息的属性（MessageProperties，在AMQP协议中定义了14中properties，这些属性会随着消息一起发送）中设置两个值replyTo（一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和correlationId（此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行失败）
- 服务器端收到消息并处理
- 服务器端处理完消息后，将生成一条应答消息到replyTo指定的Queue，同时带上correlationId属性
- 客户端之前已订阅replyTo指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId属性分析哪条请求被执行了，根据执行结果进行后续业务处理
持久化
持久化：队列和交换机有一个创建时候指定的标志durable，直译叫做坚固的。durable的唯一含义就是具有这个标志的队列和交换机会在重启之后重新建立，它不表示说在队列当中的消息会在重启后恢复。那么如何才能做到不只是队列和交换机，还有消息都是持久的呢？
但是首先一个问题是，你真的需要消息是持久的吗？对于一个需要在重启之后回复的消息来说，它需要被写入到磁盘上，而即使是最简单的磁盘操作也是要消耗时间的。如果和消息的内容相比，你更看重的是消息处理的速度，那么不要使用持久化的消息。
当你将消息发布到交换机的时候，可以指定一个标志“Delivery Mode”（投递模式）。根据你使用的AMQP的库不同，指定这个标志的方法可能不太一样。简单的说，就是将 Delivery Mode设置成2，也就是持久的即可。一般的AMQP库都是将Delivery Mode设置成1，也就是非持久的。所以要持久化消息的步骤如下：
1. 将交换机设成：durable。
2. 将队列设成：durable。
3. 将消息的：Delivery Mode 设置成2。
绑定（Bindings）如何持久化？我们无法在创建绑定的时候设置成durable。没问题，如果绑定了一个durable的队列和一个durable的交换机，RabbitMQ会自动保留这个绑定。类似的，如果删除了某个队列或交换机（无论是不是durable），依赖它的绑定都会自动删除。
注意两点：
1. RabbitMQ不允许绑定一个非坚固（non-durable）的交换机和一个durable的队列。反之亦然。要想成功必须队列和交换机都是durable的。
2. 一旦创建了队列和交换机，就不能修改其标志了。例如，如果创建了一个non-durable的队列，然后想把它改变成durable的，唯一的办法就是删除这个队列然后重现创建。因此，最好仔细检查创建的标志。
消息队列 ( MQ ) 使用过程
几个概念说明：
1. Broker：简单来说就是消息队列服务器实体。
2. Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
3. Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
4. Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
5. Routing Key：路由关键字，exchange根据这个关键字进行消息投递。
6. vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。
7. producer：消息生产者，就是投递消息的程序。
8. consumer：消息消费者，就是接受消息的程序。
9. channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。
消息队列的使用过程大概如下：
1. 客户端连接到消息队列服务器，打开一个channel。
2. 客户端声明一个exchange，并设置相关属性。
3. 客户端声明一个queue，并设置相关属性。
4. 客户端使用routing key，在exchange和queue之间建立好绑定关系。
5. 客户端投递消息到exchange。
6. exchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。
RabbitMQ 安装使用
官网安装步骤：http://www.rabbitmq.com/download.html
RabbitMQ 常用命令
1. web 界面
1) rabbitmq-plugins enable rabbitmq_management
2) invoke-rc.d rabbitmq-server stop
3) invoke-rc.d rabbitmq-server start
4) 访问http://localhost:15672 。用户名密码都是 guest
2. Linux 命令行
rabbitmqctl [-n node] [-q] {command} [command options…]
Command分类：
1) Application Management
2) Cluster Management
3) User management
4) Access control
5) Parameter Management
6) Policy Management
7) Server Status
8) Miscellaneous
RabbitMQ 命令行详见：https://www.rabbitmq.com/man/rabbitmqctl.1.man.html
-
基本的管理功能
-
stop [
<pid_file>]
-
#停止在erlang node上运行的rabbitmq，会使rabbitmq停止
-
stop_app
-
#停止erlang node上的rabbitmq的应用，但是erlang node还是会继续运行的
-
start_app
-
#启动erlan node上的rabbitmq的应用
-
wait
<pid_file>
-
#等待rabbitmq服务启动
-
reset
-
#初始化node状态，会从集群中删除该节点，从管理数据库中删除所有数据，例如vhosts等等。在初始化之前rabbitmq的应用必须先停止
-
force_reset
-
#无条件的初始化node状态
-
rotate_logs
<suffix>
-
#轮转日志文件
-
-
cluster管理
-
join_cluster
<clusternode> [–ram]
-
#clusternode表示node名称，–ram表示node以ram node加入集群中。默认node以disc node加入集群，在一个node加入cluster之前，必须先停止该node的rabbitmq应用，即先执行stop_app。
-
cluster_status
-
#显示cluster中的所有node
-
change_cluster_node_type disc | ram
-
#改变一个cluster中node的模式，该节点在转换前必须先停止，不能把一个集群中唯一的disk node转化为ram node
-
forget_cluster_node [–offline]
-
#远程移除cluster中的一个node，前提是该node必须处于offline状态，如果是online状态，则需要加–offline参数。
-
update_cluster_nodes clusternode
-
#
-
sync_queue queue
-
#同步镜像队列
-
cancel_sync_queue queue
-
#
-
-
用户管理
-
add_user
<username>
<password>
-
#在rabbitmq的内部数据库添加用户
-
delete_user
<username>
-
#删除一个用户
-
change_password
<username>
<newpassword>
-
#改变用户密码 \\改变web管理登陆密码
-
clear_password
<username>
-
#清除用户密码，禁止用户登录
-
set_user_tags
<username>
<tag> …
-
#设置用户tags
-
list_users
-
#列出用户
-
add_vhost
<vhostpath>
-
#创建一个vhosts
-
delete_vhost
<vhostpath>
-
#删除一个vhosts
-
list_vhosts [
<vhostinfoitem> …]
-
#列出vhosts
-
set_permissions [-p
<vhostpath>]
<user>
<conf>
<write>
<read>
-
#针对一个vhosts 给用户赋予相关权限
-
clear_permissions [-p
<vhostpath>]
<username>
-
#清除一个用户对vhosts的权限
-
list_permissions [-p
<vhostpath>]
-
#列出哪些用户可以访问该vhosts
-
list_user_permissions
<username>
-
#列出该用户的访问权限
-
set_parameter [-p
<vhostpath>]
<component_name>
<name>
<value>
-
#
-
clear_parameter [-p
<vhostpath>]
<component_name>
<key>
-
#
-
list_parameters [-p
<vhostpath>]
-
#
-
-
policy管理，策略用来控制和修改queues和exchange在集群中的行为，策略可以应用到vhost
-
set_policy [-p
<vhostpath>] [–priority
<priority>] [–apply-to
<apply-to>]
-
<name>
<pattern>
<definition>
-
#name 策略名称，pattern 正则表达式，用来匹配资源，符合的就会应用设置的策略，apply-to 表示策略应用到什么类型的地方，一般有queues、exchange和all，默认是all。priority 是个整数优先级，definition 是json格式设置的策略。
-
clear_policy [-p
<vhostpath>]
<name>
-
#清除一个策略
-
list_policies [-p
<vhostpath>]
-
#列出已有的策略
-
queues && exchange状态信息
-
list_queues [-p
<vhostpath>] [
<queueinfoitem> …]
-
#返回queue的信息，如果省略了-p参数，则默认显示的是”/”vhosts的信息。
-
list_exchanges [-p
<vhostpath>] [
<exchangeinfoitem> …]
-
#返回exchange的信息。
-
list_bindings [-p
<vhostpath>] [
<bindinginfoitem> …]
-
#返回绑定信息。
-
list_connections [
<connectioninfoitem> …]
-
#返回链接信息。
-
list_channels [
<channelinfoitem> …]
-
#返回目前所有的channels。
-
list_consumers [-p
<vhostpath>]
-
#返回consumers，
-
status
-
#显示broker的状态
-
environment
-
#显示环境参数的信息
-
report
-
#返回一个服务状态report，
-
eval
<expr>
-
rabbitmq支持各种插件，开启插件可以使用rabbitmq-plugins命令
-
-
插件的开启和关闭方法
-
-
rabbitmq-plugins
<command> [
<command options>]
-
Commands:
-
list [-v] [-m] [-E] [-e] [
<pattern>] 显示所有的的插件。-v 显示版本 -m 显示名称 -E 显示明确已经开启的 -e显示明确的和暗中开启的
-
enable
<plugin> … 开启一个插件
-
disable
<plugin> … 关闭一个插件
-
-
开启：rabbitmq-plugins enable rabbitmq_management
-
-
rabbitmq_management插件的用法：
-
-
web http://host:15672/
-
api http://host:15672/api/
-
cli http://host:15672/cli
rabbitMQ常用命令
RabbitMQ 服务
-
# /sbin/service rabbitmq-
server
stop
-
# /sbin/service rabbitmq-
server start
-
# rabbitmqctl status
-
-
启动rabbitmq服务命令为：rabbitmq-
server start（用户关闭连接后，自动结束进程）
-
后台运行rabbitmq服务命令为：rabbitmq-
server -detached
-
关闭服务命令为：rabbitmqctl
stop
RabbitMQ 常用命令
-
# rabbitmqctl -q status 查看状态。通过”-q”标示可选择安静模式。
-
# rabbitmqctl list_queues 查看所有队列信息
-
# rabbitmqctl stop_app 关闭 RabbitMQ 应用。若单机有多个实例，则在 rabbitmqctlh 后加 –n 指定名称
-
# rabbitmqctl start_app 启动 RabbitMQ 应用。启动 和 关闭 配合使用，可以达到清空队列的目的。
更多用法及参数，可以执行 rabbitmqctl 命令查看。或者 man rabbitmqctl
用户管理
-
# rabbitmqctl add_user username password 添加用户
-
# rabbitmqctl delete_user username 删除用户
-
# rabbitmqctl change_password username newpassword 修改密码
-
# rabbitmqctl list_users 列出所有用户
-
# rabbitmqctl set_user_tags {username} {tag ...} 设置用户角色
-
Tag可以为 administrator、monitoring、policymaker、management
-
-
(
1) 超级管理员(administrator)
-
可登陆管理控制台(启用management plugin的情况下)，可查看所有的信息，并且可以对用户，策略(policy)进行操作。
-
-
(
2) 监控者(monitoring)
-
可登陆管理控制台(启用management plugin的情况下)，同时可以查看rabbitmq节点的相关信息(进程数，内存使用情况，磁盘使用情况等)
-
-
(
3) 策略制定者(policymaker)
-
可登陆管理控制台(启用management plugin的情况下), 同时可以对policy进行管理。但无法查看节点的相关信息。
-
与administrator的对比，administrator能看到这些内容
-
-
(
4) 普通管理者(management)
-
仅可登陆管理控制台(启用management plugin的情况下)，无法看到节点信息，也无法对策略进行管理。
-
-
(
5) 其他
-
无法登陆管理控制台，通常就是普通的生产者和消费者。
-
-
-
rabbitmqctl set_user_tags test_user monitoring policymaker 也可以给同一用户设置多个角色
权限设置
-
# rabbitmqctl set_permissions [-p vhostpath] {user} {conf_reg} {write_reg} {read_reg}
-
vhostpath：Vhost路径
-
user：用户名
-
conf_reg： 配置权限的正则。表示哪些配置资源能够被该用户访问。
-
write_reg：写权限的正则。表示哪些配置资源能够被该用户写入。
-
read_reg： 读权限的正则。表示哪些配置资源能够被该用户读取。
-
-
-
用户名为
test的用户就可以访问vitrual host为test_host的资源了，并且具备读写的权限。
-
rabbitmqctl set_permissions -p test_host
test
"test-*"
".*"
".*"
-
-
-
用户名为weijh的用户就可以访问root默认虚拟主机所有的资源了，并且具备读写的权限。
-
rabbitmqctl set_permissions -p
"/" weijh
".*"
".*"
".*"
添加用户示例
-
# rabbitmqctl add_user testuser testpwd 添加用户 testuser
-
# rabbitmqctl set_permissions -p "/" testuser ".*" ".*" ".*" 为 testuser 添加权限
-
# rabbitmqctl delete_user testuser 删除 testuser 用户
虚拟主机管理
-
# rabbitmqctl add_vhost vhostpath 创建虚拟主机
-
# rabbitmqctl delete_vhost vhostpath 删除虚拟主机
-
# rabbitmqctl list_vhosts 列出所有虚拟主机
权限控制
-
# rabbitmqctl set_permissions [-p vhostpath] username regexp regexp regexp 设置用户权限
-
# rabbitmqctl clear_permissions [-p vhostpath] username 清除用户权限
-
# rabbitmqctl list_permissions [-p vhostpath] 列出虚拟主机上的所有权限
-
# rabbitmqctl list_user_permissions username 列出用户权限
显示
-
# rabbitmqctl list_queues [-p <VHostPath>] [<QueueInfoItem> ...] 查看所有队列信息
-
# rabbitmqctl list_exchanges [-p <VHostPath>] [<ExchangeInfoItem> ...]
-
# rabbitmqctl list_bindings [-p <VHostPath>]
-
# rabbitmqctl list_connections [<ConnectionInfoItem> ...]
# rabbitmqctl rotate_logs[suffix] 循环日志文件
# rabbitmqctl cluster clusternode… 集群管理
重置RabbitMQ节点
-
# rabbitmqctl reset
-
# rabbitmqctl force_reset
-
从它属于的任何集群中移除，从管理数据库中移除所有数据，例如配置过的用户和虚拟宿主, 删除所有持久化的消息。
-
force_reset 命令 和
reset 的区别是无条件重置节点，不管当前管理数据库状态以及集群的配置。
-
如果数据库或者集群配置发生错误才使用这个最后的手段。
-
注意：只有在停止RabbitMQ应用后，
reset和force_reset才能成功。
-
-
-
重置RabbitMQ节点 步骤
-
（
1）关闭rabbitmq: rabbitmqctl stop_app
-
（
2）还原： rabbitmqctl
reset
-
（
3）启动： rabbitmqctl start_app
-
（
4）添加用户： rabbitmqctl add_user root root
-
（
5）设置权限：rabbitmqctl set_permissions -p / root
".*"
".*"
".*"
-
（
6）查看用户： rabbitmqctl list_users
出于一些需要,比如我们有多个ip,我们希望rabbitmq仅运行在指定的ip上.
或者考虑到安全问题,我们希望修改一下rabbitmq的监听端口.
默认安装完成以后,在/etc下面会有一个rabbitmq的空目录,这时候我们需要手工创建rabbitmq.conf,并写入相关内容.
vi /etc/rabbitmq/rabbitmq.conf
RABBITMQ_NODE_IP_ADDRESS=0.0.0.0
RABBITMQ_NODE_PORT=2222
保存以后重启服务就生效了.
RabbitMQ 插件
http://www.rabbitmq.com/man/rabbitmq-plugins.1.man.html
RabbitMQ（一） Win7系统下的安装与配置：https://blog.csdn.net/diweikang/article/details/52094138
开启某个插件：rabbitmq-plugins enable xxx
关闭某个插件：rabbitmq-plugins disable xxx
查看rabbitmq已经安装的插件信息：/usr/rabbitmq/sbin/rabbitmq-plugins list
注意：开启某个插件后 重启服务器后生效。
rabbitmq_management 插件启动后可以在 Web页面 对 rabbitmq 进行管理
/usr/rabbitmq/sbin/rabbitmq-plugins enable rabbitmq_management
/usr/rabbitmq/sbin/rabbitmq-plugins disable rabbitmq_management
浏览器访问localhost:15672 默认账号：guest 密码：guest
rabbitmq配置
一般情况下，RabbitMQ的默认配置就足够了。如果希望特殊设置的话，有两个途径：
1. 环境变量的配置文件 rabbitmq-env.conf 。
2. 配置信息的配置文件 rabbitmq.config；
注意：这两个文件默认是没有的，如果需要必须自己创建。
示例：
rabbitmq-env.conf：
这个文件的位置是确定和不能改变的，位于：/etc/rabbitmq目录下（这个目录需要自己创建）。
#RABBITMQ_NODE_PORT= //端口号
#HOSTNAME=
RABBITMQ_NODENAME=mq
RABBITMQ_CONFIG_FILE= //配置文件的路径
RABBITMQ_MNESIA_BASE=/rabbitmq/data //需要使用的MNESIA数据库的路径
RABBITMQ_LOG_BASE=/rabbitmq/log //log的路径
RABBITMQ_PLUGINS_DIR=/rabbitmq/plugins //插件的路径
具体的列表见：http://www.rabbitmq.com/configure.html#define-environment-variables
rabbitmq.config
这是一个标准的erlang配置文件。它必须符合erlang配置文件的标准。
它既有默认的目录，也可以在rabbitmq-env.conf文件中配置。
文件的内容详见：http://www.rabbitmq.com/configure.html#config-items
rabbitmq 添加远程访问功能
http://blog.haohtml.com/archives/15249
RabbitMQ 集群配置
From: http://blog.csdn.net/cugb1004101218/article/details/21243927
rabbitMQ是用erlang开发的，集群非常方便，因为erlang天生就是一门分布式语言,但其本身并不支持负载均衡。
rabbit模式大概分为以下三种：单一模式、普通模式、镜像模式。
单一模式：最简单的情况，非集群模式。没什么好说的。
普通模式：默认的集群模式。对于Queue来说，消息实体只存在于其中一个节点，A、B两个节点仅有相同的元数据，即队列结构。当消息进入A节点的Queue中后，consumer从B节点拉取时，rabbitMQ会临时在A、B间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连A或B，出口总在A，会产生瓶颈。该模式存在一个问题就是当A节点故障后，B节点无法取到A节点中还未消费的消息实体。如果做了消息持久化，那么得等A节点恢复，然后才可被消费；如果没有持久化的话，然后就没有然后了……
镜像模式：把需要的队列做成镜像队列，存在于多个节点，属于rabbitMQ的HA方案。该模式解决了上述问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在consumer取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用(后面会详细介绍这种模式，目前我们搭建的环境属于该模式)了解集群中的基本概念：rabbitMQ的集群节点包括内存节点、磁盘节点。顾名思义内存节点就是将所有数据放在内存，磁盘节点将数据放在磁盘。不过，如前文所述，如果在投递消息时，打开了消息的持久化，那么即使是内存节点，数据还是安全的放在磁盘。一个rabbitMQ集群中可以共享 user，vhost，queue，exchange等，所有的数据和状态都是必须在所有节点上复制的，一个例外是，那些当前只属于创建它的节点的消息队列，尽管它们可见且可被所有节点读取。rabbitMQ节点可以动态的加入到集群中，一个节点它可以加入到集群中，也可以从集群环集群会进行一个基本的负载均衡。
集群中有两种节点：
内存节点：只保存状态到内存（一个例外的情况是：持久的queue的持久内容将被保存到disk）
磁盘节点：保存状态到内存和磁盘。内存节点虽然不写入磁盘，但是它执行比磁盘节点要好。集群中，只需要一个磁盘节点来保存状态 就足够了 如果集群中只有内存节点，那么不能停止它们，否则所有的状态，消息等都会丢失。
</div>
扫一扫
966
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
