一个8年工作经验的小伙伴，被问到这样一个问题，说如何保证RabbitMQ的高可用。关于这个问题呢，这位小伙伴倒是有个实操经验，就是不知道如何组织语言。所以，当时面试结果不太理想。今天，我给大家分享一下我的理解。
另外，我花了很长时间，准备了一份500页的PDF面试资料文档和一份10W字的Java总结面试题和答案，
1、实现思路
所谓高可用呢，就是指分布式系统中，如果出现某些节点不可用的情况下，要保证客户端依旧还能够连接到其他节点，而不至于影响业务的执行。我主要从以下两个方面来实现高可用，一个是集群部署，一个是负载均衡。
ENTER TITLE
RabbitMQ是用Erlang语言编写的，而Erlang天生具备分布式的特性，所以不需要通过引入ZK来实现服务协调。它是使用.erlang.cookie来验证身份，它通过25672端口来实现集群。这个cookie就像暗号一样，只要喊出清楚明白666，就知道是Tom的粉丝。
另外，RabbitMQ的集群节点有两种，一种是磁盘节点（Disc Node），一种是内存节点（RAM Node）。在集群环境中至少需要一个磁盘节点用来持久化元数据，否则，当全部内存节点崩溃时，就无从同步元数据。
下面，分享一下RabbitMQ的集群模式，分别是普通集群模式和镜像队列模式。先来看普通集群模式。
2、普通集群
普通集群模式下，不同的节点之间只会相互同步元数据，而不会同步消息内容。
ENTER TITLE
如图所示，队列A的消息只存储在A节点上。B节点和C节点同步了队列A的元数据，但是没有同步队列中的内容。
假如生产者连接的是C节点，要将消息通过交换机A路由到队列A，最终消息还是会转发到A节点上存储，因为队列A存储在A节点上。
同理，如果消费者连接是B节点，同样也要从队列A上拉取消息，消息会从A节点转发到节点B。其它节点只是起到一个路由的作用。
这样做的好处是，可以节约存储和同步数据的网络开销。但如果需要保证队列的高可用性，这时候，就需要用到镜像集群的模式。
3、镜像集群
下面来看镜像集群模式，如图所示，
ENTER TITLE
其实也非常好理解，在镜像队列模式下，消息内容会在所有的镜像节点间同步，可用性更高。不过也有一定的副作用，系统性能会降低，节点过多的情况下同步数据的代价会比较大。
4、负载均衡
集群搭建成功后，要保证高可用，还需要一个负载均衡的组件（例如HAProxy，LVS，Nignx），由负载的组件来做路由。对于，生产者或者消费者而言，只需要连接到负载组件的虚拟IP地址就可以了。
这个负载均衡组件需要满足以下几个条件：
1、它本身有负载功能，可以监控集群中节点的状态，如果某个节点出现异常或者发生故障，就把它剔除掉。
2、为了提高可用性，要能够支持部署多个服务，能够自主完成Master选举
3、Master节点需要对外提供一个虚拟IP，客户端只需要连接到这一个虚拟IP就可以自动完成真实IP的路由。
下面我以HAProxy加Keepalived组合，来实现RabbitMQ的高可用，具体架构如图所示：
ENTER TITLE
当然，实现高可用的方案还有很多，比如我们还可以用LVS，Nignx等等来实现负载均衡。
关于RabbitMQ的高可用方案我就分享这么。我分享的这个方案，不仅仅只适用于RabbitMQ，其实还可以应用于大部分的分布式高可用场景。小伙伴们如果你还有其他更加牛B的方案，可以在评论区告诉我相互学习一下。
最后，我把之前分享的视频全部整理成了文字，希望能够以此来提高各位粉丝的通过率。
ENTER TITLE
