这两天碰到了测试RabbitMQ的高可用，无奈研发双手一摊说没方案大致原理就是镜像队列备份看着测吧，好想掀桌而起怒吼你是研发你不能不知道啊，算了，搞了几天总算弄完了写下来供有需要的人参考，网上关于高可用之镜像队列的原理讲解很多，这篇主要是详细描述一下在我的生产环境中可以怎样粗略测试高可用，人为创造down掉的环境来使得新手直观感受RabbitMQ的镜像队列。

参考资料

https://yq.aliyun.com/articles/683088
https://blog.csdn.net/qq_41097820/article/details/88793329

具体测试方案

首先创建rabb集群模式（副本数为3），在创建的时候设置亲和性与反亲和性，亲和性保证三个pod起在指定的三台主机上，反亲和保证两个pod不起在同一台主机上（后续会讲为什么这样做）。
具体做法：在指定的三台主机上加特定标签（我加的是wyj:false)，并且按照反亲和的规则查看server的特有标签（这里的例子是app.kubernetes.io/name: 实例name）。
在yaml里直接添加：

affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: wyj
                operator: In
                values:
                  - 'false'
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app.kubernetes.io/name: bbb
          topologyKey: kubernetes.io/hostname

等待pod成功启动之后，添加内部路由，容器端口写15672（rabb的服务端口），导入statefulset的server（真正的服务pod）计算资源，然后创建成功后查看其生成的主机端口。
通过nodeip+主机端口访问rabb的web页面，使用secret登录进去。
按照某个教程熟悉并且快速掌握web界面的使用，创建exchange、queue、并且进行绑定（以下web界面的步骤均可以通过cli命令进行）。
我这里暂且设置一个exchange，三个queue，并且bind时选择默认类型routine key也要填写queue的name。
之后可以试着使用exchange给queue发送message，然后queue接受message看下搭建是否成功（get message时可以选择两种模式，默认模式不会从queue中取出，ack模式读完一条取出一条）。

此时如果我们使其中接收到消息的queue所在节点（集群模式下创建queue可以指定其所起的server，因为我们创建pod时起在不同的节点上，因此queue就在不同的节点上）的server永远的起不来（不能直接delete，k8s会自动重启，具体方案见后面），此时queue状态会down掉，消息丢失，如下

那么这个时候rabb的镜像队列就派上用场了，通过设定镜像队列我们可以使得消息产生备份，从而验证高可用。
设置镜像队列的方法（web版本），这里我们设置镜像队列的策略如下（参数见官方文档或者自行百度）：

意味着自动同步到集群中所有节点，设置成功后设定的镜像队列出现+2标志（两个备份）：

此时我们再使得这条queue状态down掉，可以看到镜像备份变为+1，少了一份，但消息仍然是可以get的，原理在这里中已经说得很清楚了，至此高可用验证成功。

模拟生产中服务down掉的方案

我们RabbitMQ的集群模式建立队列时可以选择对应的server，而server部署在不同的pod上，而pod我们已经设置了亲和性与反亲和性，亲和性保证三个pod起在指定的三台主机上，反亲和保证两个pod不起在同一台主机上，这样我们可以使得一个pod永不起来（对应的服务也不会起来），只要将此pod所在的节点先停止调度（新起的pod不会在这个node上），然后重启要搞的pod即可，此pod没有能用的node，就可以开心地看它pending的状态了。