由于业务的需要用到队列，并保证队列的高可用性，我们选择了RabbitMQ的镜像集群模式。这种集群模式在队列节点宕机或故障时也能正常使用，因为它支持复制队列内容到集群里的每个节点。
OK，关于RabbitMQ的基本知识就不在这里普及了，直接看我们总结的需要关注的几个可用性测试点：
1. 在集群工作中如果一个或几个节点宕机会不会导致队列数据的丢失？
2. DISC的节点可以在其宕机重启后保存队列数据吗？
3. RAM和DISC模式的速度差有多大？有没有必要所有节点都采用DISC模式？
4. 影响上游生产者和下游消费者的发送和接收的情况会有哪些？何时会导致连接问题？
有了以上的问题，我们就可以部署我们的测试了，首先当然是集群环境搭建，这里不会花篇幅在搭建上，网上的例子很多，比如：环境搭建
我们测试用会有三台机器，1台为DISC模式（磁盘），另外两台为RAM模式（内存）。在完成了环境搭建后，我们的集群应该满足下列的条件：
a. 在3台物理机的控制台分别输入rabbitmqctl cluster_status后：
可以看到三个控制台的输出都是差不多的，而且一台为disc模式：rabbit@7-2；另外两台是ram模式：rabbit@7-3和rabbit@7-15
b. 分别打开三个RabbitMQ的网页管理端并创建和配置vHost，Queue，Policy等（具体步骤省略，可参考上面环境配置网页），展示为：
Overview页面（显示的集群中各节点的状态都是正确的）
Queue页面（我们可以看到在Node项下有一个“+2”，表示集群还有两个节点和本节点是镜像同步模式）
满足了上面的条件，我们就可以开始测试集群了。
1. 在集群工作中如果一个或几个节点宕机会不会导致队列数据的丢失？
我们可以先往某一个队列里写1000个数据：
然后查看3个RabbitMQ的网页管理端的Queue页面，Messages里面Ready的数据为1000个：
通过查询3个RabbitMQ的网页管理端的Queue页面，可以看到3个端中Queue页面的数据都是一样的（如上图），全部都是有1000个数据，单从页面上看，几个节点应该是完成了数据的镜像复制，就是说现在任何一个节点或者多个节点宕机，只要还剩一个节点存活，我们的数据就还是可以被消费了，那好，我们就关掉两台节点：rabbit@7-3和rabbit@7-15
ps：关掉节点的语句是 rabbitmqctl stop_app
两个节点关闭后么可以看到网页管理端的Queue页面的变化：
可以看到，Node里面的“+2”标志消失了，代表现在集群中只有一个节点rabbit@7-2了；从图上也可以看到，Messages里面的消息数量还是1000没有变，我们现在就写个消费者获取下，看看是不是能够获得这1000个消息数据。
通过试验，我们发现发送的1000个消息都可以收到，所以，在集群工作中如果一个或几个节点宕机是不会导致队列数据的丢失的。
2. DISC的节点可以在其宕机重启后保存队列数据吗？
我们搭建的集群的DISC节点是rabbit@7-2，那我们就针对它进行这个测试。
还是先发送1000个消息给集群：
确认将三个节点全部挂掉（没有running nodes）：
确认后将三个节点打开并通过网页管理端的Queue页面查看：
可以看到，消息还是1000个，没有丢。但是有个细节，Node下面有了些变化。有了一个红色的“+2”出现，它的意思是现在集群中有两个节点（rabbit@7-3和rabbit@7-15）还没有实现镜像同步，因为之前有1000个消息它们两个节点不知道（因为是RAM的，重启后就消失了）。但是我们可以从rabbit@7-3和rabbit@7-15获得这1000个消息吗？试试看的结果是：可以！
消息都消费完后，网页管理端的Queue页面变为了：
3. RAM和DISC模式的速度差有多大？有没有必要所有节点都采用DISC模式？
为了测试这个，我们单独选出来了两个Node进行点对点的测试：rabbit@7-3（RAM）和rabbit@7-2（RAM），并采用1000/s的频率发送消息，计算速度的方式为：AVERAGE（消费者接收到消息的时间 - 生产者发送消息的时间）
将生产者和消费者程序中的Node节点统一变为rabbit@7-2的IP后，先打开消费者，再打开生产者，此种情况下计算出的消息速度为：8.33ms
将生产者和消费者程序中的Node节点统一变为rabbit@7-3的IP后，先打开消费者，再打开生产者，此种情况下计算出的消息速度为：3.36ms
可以看到，RAM节点的消息速度比DISC的速度快2.5~3倍。而且随着发送频率的增加，这个速度差距会越来越大。所以，在实际应用中，如果对消息的速度要求很高，建议还是以RAM节点为主。
4. 影响上游生产者和下游消费者的发送和接收的情况会有哪些？何时会导致连接问题？
其实，影响生产者和消费者发送和接收消息的情况很多，根据我们之前做的测试，RabbitMQ集群中只要不是全部节点全挂掉，我们就不会停止传输消息。但这并不意味着你的系统就完全的高枕无忧了，因为你如何和RabbitMQ集群连接是个关键问题，比如如果在程序中写死了连接的节点IP，这个节点挂掉的话那就是连不上了，集群也无能为力。
目前应该有两个可行的方法使集群起到作用：
1. 在集群前端加一个LB，统一为一个IP和端口，负载均衡和节点轮询全都交给它就好了，但是要注意DISC的分配问题，不使用或优先级降低。
2. 自己的程序实现节点轮询。这个需要程序人员自己写了，来实现上述LB的功能。
网友评论