1.安装erlang & RabbitMQ

要想安装RabbitMQ，首先需要安装和配置好它的宿主环境erlang。去erlang官网下载好erlang otp_src源码包，然后在本地执行源码安装。（erlang官网：http://www.erlang.org/）

由于我本机已经下载好了otp_src源码包，我是使用的otp_src_19.1版本。下载好之后解压缩，然后进入目录，执行./configure --prefix=/usr/erlang/，进行环境的检查和安装路径的选择。

如果你提示“No curses library functions found”错误，是因为缺少curses库，yum install –y ncurses-devel。安装后在进行configure。

如果没有报错的话，就说明安装成功了。

你还需要配置下环境变量：

export PATH=$PATH:/usr/erlang/bin

source /etc/profile

此时使用erl命令检查下erlang是否能正常工作了。接下来安装RabbitMQ，去官网下载运行的包就行了。同样要配置下环境变量，这样你的命令才能被系统查找到。然后运行rabbitmq实例。

这里有一个需要注意，记得配置下hosts，在127.0.0.1里加上本机的名称。erlang进程需要host来进行连接，所以它会检查你的hosts配置。

还需要设置下防火墙，三个端口要打开。15672是管理界面用的，25672是集群之间使用的端口，4369是erlang进程epmd用来做node连接的。

我配置了两个节点，192.168.0.105、192.168.0.107，现在已经全部就绪。我们添加原始账号进入rabbitmq管理界面。

2.配置RabbitMQ cluster

先保证你的各个rabbitmq节点都是可以访问的，且打开rabbitmq_management plugin，这样可以当出现某个节点挂掉之后可以切换到其他管理界面查看情况或者管理。

打开管理界面插件：

rabbitmq-plugins enable rabbitmq_management

添加账号：

rabbitmqctl add_user admin admin

添加 权限tag

rabbitmqctl set_user_tags admin administrator

保证两个节点都是可以正常工作的。下面我们就将这两个节点连接起来形成高可用的cluster，这样我们就可以让我们的exchange、queue在这两个节点之间复制，形成高可用的queue。

cd 到你的home目录下，我是在root下，里面有一个隐藏的.erlang.cookie文件，这就是我在前面介绍erlang时候提到的，这个文件是erlang用来发现和互连的基础。

我们需要做的很简单，将两个节点中的.erlang.cookie设置成一样的。这是erlang的约定，一样的cookie hash key他认为是合法和正确的连接。

.erlang.cookie默认是只读的，你需要修改下写入权限，然后复制粘贴下cookie 字符串即可。

chmod u+w .erlang.cookie

配置好了之后接下来配置hosts文件，erlang会使用hosts文件里的配置去发现节点。

vim /etc/hosts

192.168.0.107 rabbitmq_node2

192.168.0.105 rabbitmq_node1

保证同样的配置在所有的节点上都是相同的。验证你配置的正确不正确你只需要在你的机器上ping rabbitmq_node1，试下请求的ip是不是你配置的即可。

按照DNS的请求原理，hosts是最高优先权，除非浏览器有缓存，你直接用ping就不会有问题的。

选择一个节点stop，然后连接到另外节点。

rabbitmqctl stop_app

rabbitmqctl join_cluster rabbit@rabbitmq_node2

Clustering node rabbit@rabbitmq_node1 with rabbit@rabbitmq_node2 ...

rabbitmqctl start_app

节点已经连接成功。

默认情况下节点占用的memory是总内存的40%，可以根据自己的用途仔细研究rabbitmq的配置项。

为了提高性能，不需要两个节点都是disc的节点，所以我们需要启动一个节点为RAM模式。

rabbitmqctl change_cluster_node_type ram

改变rabbitmq_node1为内存节点模式。

3.Mirror queue policy设置

节点是准备好了，接下来我们需要设置exchange、queue 高可用策略，这样才能真的做到高可用。

现在是物理上的机器或者说虚拟机节点是高可用的，但是里面的对象需要我们进行配置策略。

RabbitMQ支持很好的策略模式，需要管理员才能操作。

首先我们需要创建一个属于自己业务范围内的vhost，标示一个逻辑上的独立空间，所有的账号、策略、队列都是强制在某个虚拟机里的。我创建了一个common vhost。

开始添加policie。

最主要是Apply to ，可以作用在exchange或者queues上，当然也可以包含这两个。

策略选择还是比较丰富的，最常用的是HAmode，还有MessageTTL（消息的过期时间）。

这些策略按照几个维度分组了，有跟高可用相关的，有Federation（集群之间同步消息）相关的 ，有Queue相关的，还有Exchange相关的。可以根据的业务场景进行调整。

我们定义了策略的匹配模式.order.，这样可以避免将所有的exchange、queue都镜像了。

我们新建了一个ex.order.topic exchange，它的features中应用了exchange_queue_ha策略（相同的策略是无法叠加使用的）。

其他的exchange并没有应用这个策略，是因为我们的pattern限定了只匹配.order.的名称。

创建一个qu.order.crm queue，注意看它的node属性里有一个”Synchronised mirrors:rabbit@rabbitmq_node2“镜像复制。

features里也应用了exchange_queue_ha策略。这个时候，队列其实在两个节点里都是有的，虽然我们创建的时候是在rabbit@rabbitmq_node1里的，但是它会复制到集群里的其他节点。

在创建HAmode的时候可以提供HA params参数，来限定复制节点的个数，这通常用来提高性能和HA之间的平衡。

4.两个不错的RabbitMQ plugin 大型应用插件(Sharding、Rederation)

在rabbitmq-plugins中有两个plugin还是可以试着研究研究的。rabbitmq-plugins list。

rabbitmq-plugins list

Configured: E = explicitly enabled; e = implicitly enabled

| Status: * = running on rabbit@rabbitmq_node1

|/

[e*] amqp_client 3.6.5

[ ] cowboy 1.0.3

[ ] cowlib 1.0.1

[e*] mochiweb 2.13.1

[ ] rabbitmq_amqp1_0 3.6.5

[ ] rabbitmq_auth_backend_ldap 3.6.5

[ ] rabbitmq_auth_mechanism_ssl 3.6.5

[ ] rabbitmq_consistent_hash_exchange 3.6.5

[ ] rabbitmq_event_exchange 3.6.5

[ ] rabbitmq_federation 3.6.5

[ ] rabbitmq_federation_management 3.6.5

[ ] rabbitmq_jms_topic_exchange 3.6.5

[E*] rabbitmq_management 3.6.5

[e*] rabbitmq_management_agent 3.6.5

[ ] rabbitmq_management_visualiser 3.6.5

[ ] rabbitmq_mqtt 3.6.5

[ ] rabbitmq_recent_history_exchange 1.2.1

[ ] rabbitmq_sharding 0.1.0

[ ] rabbitmq_shovel 3.6.5

[ ] rabbitmq_shovel_management 3.6.5

[ ] rabbitmq_stomp 3.6.5

[ ] rabbitmq_top 3.6.5

[ ] rabbitmq_tracing 3.6.5

[ ] rabbitmq_trust_store 3.6.5

[e*] rabbitmq_web_dispatch 3.6.5

[ ] rabbitmq_web_stomp 3.6.5

[ ] rabbitmq_web_stomp_examples 3.6.5

[ ] sockjs 0.3.4

[e*] webmachine 1.10.3

rabbitmq_sharding、rabbitmq_federation，rabbitmq_sharding的版本有点低了，github地址：

https://github.com/rabbitmq/rabbitmq-sharding

Rederation 可以用来进行跨cluster或者node之间同步消息。

http://www.rabbitmq.com/federated-exchanges.html

这个用来在不同的domain之间传递消息还是个不错的解决方案，跨机房或者跨网络区域，订阅别人的rabbitmq消息始终不太稳定，可以用这种方式来传递消息。

5.Queue镜像失败手动同步

有时候可能由于各种原因导致queue mirror失败，这个时候可以手动进行同步，而不是像其他分布式系统来重启节点或者重建数据。

这个还是比较方便的，有时候总有那么几个小问题需要你手动处理的。

6.各集群配置同步方式（RabbitMQ export\import）

各个环境的集群配置同步也是个日常运维的问题，还好RabbitMQ也提供了相关工具。

7.客户端连接方式（尽量采用AMQP组来动态链接）

由于RabbitMQ是AMQP协议的实现，所以在进行远程连接的时候尽量采用amqp协议的方式连接。

var
amqpList
=

new

List

{


new

AmqpTcpEndpoint
(
new

Uri
(
"amqp://192.168.0.105:5672"
)),


new

AmqpTcpEndpoint
(
new

Uri
(
"amqp://192.168.0.107:5672"
))

};

关于集群的vip方案其实也是需要综合考虑的，如果是统一的地址会面临三个问题，DNS、LoadBalance、VIP，这三个点都有可能导致集群连接不上。

现在越来越多的方案倾向于在客户端做负载和故障转移，这有很多好处，消除了中间节点带来的故障概率。如果这三个点加在一起出现的可用性指标肯定是比直接在客户端连接的低的多。

我们碰到最多就是VIP的问题，这类系统的VIP不同于数据库，数据库的master\slave大多都是要人工check后才切换，不会随便自动的切换主从库。

而非数据库的VIP大多都是Keepalived自动检测切换，这带来一些列问题，包括连接重试、心跳保持。这只是VIP的出错场景之一。

还有LoadBalance带来的问题，DNS出错的可能性也是很大。所以我倾向于使用客户端来做这些。

有几个地方很重要，第一个就是消息的Persistent持久化状态要带上，第二个就是ContentType，这个属性很实用，方便你查看消息的正文。

如果没设置，默认是null。

第三个就是AutomaticRecoveryEnabled，自动连接重试，这致命重要。当上面的VIP切换之后这个可以保命。

第四个就是TopologyRecoveryEnabled，重新恢复Exchange、queue、binding。在出现网络断开之后，一旦恢复连接就会恢复这些设置以保证是最新的设置。

不管rabbitmq保证的多么强壮，多么高可用，记住一定要有备用方案。

1.安装erlang & RabbitMQ

要想安装RabbitMQ，首先需要安装和配置好它的宿主环境erlang。去erlang官网下载好erlang otp_src源码包，然后在本地执行源码安装。（erlang官网：http://www.erlang.org/）

由于我本机已经下载好了otp_src源码包，我是使用的otp_src_19.1版本。下载好之后解压缩，然后进入目录，执行./configure --prefix=/usr/erlang/，进行环境的检查和安装路径的选择。

如果你提示“No curses library functions found”错误，是因为缺少curses库，yum install –y ncurses-devel。安装后在进行configure。

如果没有报错的话，就说明安装成功了。

你还需要配置下环境变量：

export PATH=$PATH:/usr/erlang/bin

source /etc/profile

此时使用erl命令检查下erlang是否能正常工作了。接下来安装RabbitMQ，去官网下载运行的包就行了。同样要配置下环境变量，这样你的命令才能被系统查找到。然后运行rabbitmq实例。

这里有一个需要注意，记得配置下hosts，在127.0.0.1里加上本机的名称。erlang进程需要host来进行连接，所以它会检查你的hosts配置。

还需要设置下防火墙，三个端口要打开。15672是管理界面用的，25672是集群之间使用的端口，4369是erlang进程epmd用来做node连接的。

我配置了两个节点，192.168.0.105、192.168.0.107，现在已经全部就绪。我们添加原始账号进入rabbitmq管理界面。

2.配置RabbitMQ cluster

先保证你的各个rabbitmq节点都是可以访问的，且打开rabbitmq_management plugin，这样可以当出现某个节点挂掉之后可以切换到其他管理界面查看情况或者管理。

打开管理界面插件：

rabbitmq-plugins enable rabbitmq_management

添加账号：

rabbitmqctl add_user admin admin

添加 权限tag

rabbitmqctl set_user_tags admin administrator

保证两个节点都是可以正常工作的。下面我们就将这两个节点连接起来形成高可用的cluster，这样我们就可以让我们的exchange、queue在这两个节点之间复制，形成高可用的queue。

cd 到你的home目录下，我是在root下，里面有一个隐藏的.erlang.cookie文件，这就是我在前面介绍erlang时候提到的，这个文件是erlang用来发现和互连的基础。

我们需要做的很简单，将两个节点中的.erlang.cookie设置成一样的。这是erlang的约定，一样的cookie hash key他认为是合法和正确的连接。

.erlang.cookie默认是只读的，你需要修改下写入权限，然后复制粘贴下cookie 字符串即可。

chmod u+w .erlang.cookie

配置好了之后接下来配置hosts文件，erlang会使用hosts文件里的配置去发现节点。

vim /etc/hosts

192.168.0.107 rabbitmq_node2

192.168.0.105 rabbitmq_node1

保证同样的配置在所有的节点上都是相同的。验证你配置的正确不正确你只需要在你的机器上ping rabbitmq_node1，试下请求的ip是不是你配置的即可。

按照DNS的请求原理，hosts是最高优先权，除非浏览器有缓存，你直接用ping就不会有问题的。

选择一个节点stop，然后连接到另外节点。

rabbitmqctl stop_app

rabbitmqctl join_cluster rabbit@rabbitmq_node2

Clustering node rabbit@rabbitmq_node1 with rabbit@rabbitmq_node2 ...

rabbitmqctl start_app

节点已经连接成功。

默认情况下节点占用的memory是总内存的40%，可以根据自己的用途仔细研究rabbitmq的配置项。

为了提高性能，不需要两个节点都是disc的节点，所以我们需要启动一个节点为RAM模式。

rabbitmqctl change_cluster_node_type ram

改变rabbitmq_node1为内存节点模式。

3.Mirror queue policy设置

节点是准备好了，接下来我们需要设置exchange、queue 高可用策略，这样才能真的做到高可用。

现在是物理上的机器或者说虚拟机节点是高可用的，但是里面的对象需要我们进行配置策略。

RabbitMQ支持很好的策略模式，需要管理员才能操作。

首先我们需要创建一个属于自己业务范围内的vhost，标示一个逻辑上的独立空间，所有的账号、策略、队列都是强制在某个虚拟机里的。我创建了一个common vhost。

开始添加policie。

最主要是Apply to ，可以作用在exchange或者queues上，当然也可以包含这两个。

策略选择还是比较丰富的，最常用的是HAmode，还有MessageTTL（消息的过期时间）。

这些策略按照几个维度分组了，有跟高可用相关的，有Federation（集群之间同步消息）相关的 ，有Queue相关的，还有Exchange相关的。可以根据的业务场景进行调整。

我们定义了策略的匹配模式.order.，这样可以避免将所有的exchange、queue都镜像了。

我们新建了一个ex.order.topic exchange，它的features中应用了exchange_queue_ha策略（相同的策略是无法叠加使用的）。

其他的exchange并没有应用这个策略，是因为我们的pattern限定了只匹配.order.的名称。

创建一个qu.order.crm queue，注意看它的node属性里有一个”Synchronised mirrors:rabbit@rabbitmq_node2“镜像复制。

features里也应用了exchange_queue_ha策略。这个时候，队列其实在两个节点里都是有的，虽然我们创建的时候是在rabbit@rabbitmq_node1里的，但是它会复制到集群里的其他节点。

在创建HAmode的时候可以提供HA params参数，来限定复制节点的个数，这通常用来提高性能和HA之间的平衡。

4.两个不错的RabbitMQ plugin 大型应用插件(Sharding、Rederation)

在rabbitmq-plugins中有两个plugin还是可以试着研究研究的。rabbitmq-plugins list。

rabbitmq-plugins list

Configured: E = explicitly enabled; e = implicitly enabled

| Status: * = running on rabbit@rabbitmq_node1

|/

[e*] amqp_client 3.6.5

[ ] cowboy 1.0.3

[ ] cowlib 1.0.1

[e*] mochiweb 2.13.1

[ ] rabbitmq_amqp1_0 3.6.5

[ ] rabbitmq_auth_backend_ldap 3.6.5

[ ] rabbitmq_auth_mechanism_ssl 3.6.5

[ ] rabbitmq_consistent_hash_exchange 3.6.5

[ ] rabbitmq_event_exchange 3.6.5

[ ] rabbitmq_federation 3.6.5

[ ] rabbitmq_federation_management 3.6.5

[ ] rabbitmq_jms_topic_exchange 3.6.5

[E*] rabbitmq_management 3.6.5

[e*] rabbitmq_management_agent 3.6.5

[ ] rabbitmq_management_visualiser 3.6.5

[ ] rabbitmq_mqtt 3.6.5

[ ] rabbitmq_recent_history_exchange 1.2.1

[ ] rabbitmq_sharding 0.1.0

[ ] rabbitmq_shovel 3.6.5

[ ] rabbitmq_shovel_management 3.6.5

[ ] rabbitmq_stomp 3.6.5

[ ] rabbitmq_top 3.6.5

[ ] rabbitmq_tracing 3.6.5

[ ] rabbitmq_trust_store 3.6.5

[e*] rabbitmq_web_dispatch 3.6.5

[ ] rabbitmq_web_stomp 3.6.5

[ ] rabbitmq_web_stomp_examples 3.6.5

[ ] sockjs 0.3.4

[e*] webmachine 1.10.3

rabbitmq_sharding、rabbitmq_federation，rabbitmq_sharding的版本有点低了，github地址：

https://github.com/rabbitmq/rabbitmq-sharding

Rederation 可以用来进行跨cluster或者node之间同步消息。

http://www.rabbitmq.com/federated-exchanges.html

这个用来在不同的domain之间传递消息还是个不错的解决方案，跨机房或者跨网络区域，订阅别人的rabbitmq消息始终不太稳定，可以用这种方式来传递消息。

5.Queue镜像失败手动同步

有时候可能由于各种原因导致queue mirror失败，这个时候可以手动进行同步，而不是像其他分布式系统来重启节点或者重建数据。

这个还是比较方便的，有时候总有那么几个小问题需要你手动处理的。

6.各集群配置同步方式（RabbitMQ export\import）

各个环境的集群配置同步也是个日常运维的问题，还好RabbitMQ也提供了相关工具。

7.客户端连接方式（尽量采用AMQP组来动态链接）

由于RabbitMQ是AMQP协议的实现，所以在进行远程连接的时候尽量采用amqp协议的方式连接。

var
amqpList
=

new

List

{


new

AmqpTcpEndpoint
(
new

Uri
(
"amqp://192.168.0.105:5672"
)),


new

AmqpTcpEndpoint
(
new

Uri
(
"amqp://192.168.0.107:5672"
))

};

关于集群的vip方案其实也是需要综合考虑的，如果是统一的地址会面临三个问题，DNS、LoadBalance、VIP，这三个点都有可能导致集群连接不上。

现在越来越多的方案倾向于在客户端做负载和故障转移，这有很多好处，消除了中间节点带来的故障概率。如果这三个点加在一起出现的可用性指标肯定是比直接在客户端连接的低的多。

我们碰到最多就是VIP的问题，这类系统的VIP不同于数据库，数据库的master\slave大多都是要人工check后才切换，不会随便自动的切换主从库。

而非数据库的VIP大多都是Keepalived自动检测切换，这带来一些列问题，包括连接重试、心跳保持。这只是VIP的出错场景之一。

还有LoadBalance带来的问题，DNS出错的可能性也是很大。所以我倾向于使用客户端来做这些。

有几个地方很重要，第一个就是消息的Persistent持久化状态要带上，第二个就是ContentType，这个属性很实用，方便你查看消息的正文。

如果没设置，默认是null。

第三个就是AutomaticRecoveryEnabled，自动连接重试，这致命重要。当上面的VIP切换之后这个可以保命。

第四个就是TopologyRecoveryEnabled，重新恢复Exchange、queue、binding。在出现网络断开之后，一旦恢复连接就会恢复这些设置以保证是最新的设置。

不管rabbitmq保证的多么强壮，多么高可用，记住一定要有备用方案。