你的位置:首页 > 软件开发 > ASP.net > 应用.Net+Consul维护RabbitMq的高可用性

应用.Net+Consul维护RabbitMq的高可用性

发布时间:2016-10-21 12:00:04
懒人学习的过程就是工作中老大让干啥让做啥就研究研究啥,国庆放假回来的周末老大通过钉钉给我布置了个任务, RabbitMQ高可用解决方案,我想说钉钉太坑了:这是国庆过后9号周日晚上下班给的任务,我周一看到的时候一看,下周五,那岂不是21号,时间是如此的充裕!那不还早呢么。。恰巧 ...

  懒人学习的过程就是工作中老大让干啥让做啥就研究研究啥,国庆放假回来的周末老大通过钉钉给我布置了个任务, RabbitMQ高可用解决方案,我想说钉钉太坑了:

应用.Net+Consul维护RabbitMq的高可用性

这是国庆过后9号周日晚上下班给的任务,我周一看到的时候一看,下周五,那岂不是21号,时间是如此的充裕!那不还早呢么。。恰巧同学要面试了9号晚上一起吃饭,然后问了我几个算法,然后被鄙视了。。他说我一个前端都比你做后台的算法牛逼,你请客吧-。-于是周一到周三光学算法了(程序员为了吹牛逼,哪有啥节操啊)直到周四老大说,明天任务到期了!研究咋样了!此时才恍然大悟,钉钉你个坑货,下周五是14号!!

RabbitMQ 高可用集群

简单配置

  对于RabbitMQ 高可用集群的说明,我觉得这篇文章讲的挺详细的,就不说了。配置集群的方式看官网就可以了 ,为了采取所谓的Active/Active方案,所以只能选镜像模式了(3.x版本以上才支持).再抄一段解释过来(与普通集群相比,其实质和普通模式不同之处在于,消息实体会主动在镜像节点间同步,而不是在 consumer 取数据时临时拉取。该模式带来的副作用也很明显,除了降低系统性能外,如果镜像队列数量过多,加之大量的消息进入,集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用),在搭建好RabbitMq集群以后,

镜像模式可以通过命令行为队列添加同步策略,比如

为所有队列应用镜像模式的策略

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'

或者指定指定队列名的:

rabbitmqctl set_policy yu-ha "^yu" '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'

或者直接在管理页面添加

点击Admin菜单-->右侧的Policies选项-->左侧最下下边的Add / update a policy

应用.Net+Consul维护RabbitMq的高可用性

 

 

name就是队列名,Pattern就是匹配的规则,比如写个^yu就是以yu开头的队列,ha-mode=啥就是会同步什么队列,比如=all的话就是同步所有匹配的队列。

然后新建队列的时候就可以指定那台机器上跑主队列了。

所谓的坑

       还是抄一下这篇文章的内容,常用的手段就是通过HAProxy+KeepAlive保证RabbitMq的集群高可用:

应用.Net+Consul维护RabbitMq的高可用性

创建 queue 的过程:

  1. LB 将 client request 分发到 node 2,client 创建队列 “NewQueue”,然后开始向其中放入 message。
  2. 最终,后端服务会对 node 2 上的 “NewQueue” 创建一个快照,并在一段时间内将其拷贝到node 1 和 3 上。这时候,node2 上的队列是 master Queue,node 1 和 3 上的队列是 slave queue。

假如现在 node2 宕机了:

  • node 2 不再响应心跳,它会被认为已经被从集群中移出了
  • node 2 上的 master queue 不再可用
  • RabbitMQ 将 node 1 或者 3 上的 salve instance 升级为 master instance

假设 master queue 还在 node 2 上,客户端通过 LB 访问该队列:

  1. 客户端连接到集群,要访问 “NewQueue” 队列
  2. LB 根据配置的轮询算法将请求分发到一个节点上
  3. 假设客户端请求被转到 node 3 上
  4. RabbitMQ 发现 “NewQueue” master node 是 node 2
  5. RabbitMQ 将消息转到 node 2 上
  6. 最终客户端成功连接到 node 2 上的 master 队列

可见,这种配置下,2/3 的客户端请求需要重定向,这会造成大概率的访问延迟,但是终究访问还是会成功的。要优化的话,总共有两种方式:

  • 直接连到 master queue 所在的节点,这样就不需要重定向了。但是对这种方式,需要提前计算,然后告诉客户端哪个节点上有 master queue。
  • 尽可能地在所有节点间平均分布队列,减少重定向概率

 为了避免这种n-1/n的这种重定向,知道Master queue所在的节点很重要啊,接下来就不抄了。

思路

     大致的意思就是这张图:

 应用.Net+Consul维护RabbitMq的高可用性

  1.将RabbitMq注册到Consul中(步骤1),通过Consul对RabbitMq进行健康监测,同时Consul提供配置中心的服务,可以存储一些RabbitMq的配置信息,比如队列账号,密码,队列主机名,所在Ip等,举个例子:

  将RabbitMq服务注册到Consul:  

应用.Net+Consul维护RabbitMq的高可用性应用.Net+Consul维护RabbitMq的高可用性
{  "services": [{   "id":"rabbit@rabbitmq1",   "name":"RabbitMqServer",   "tags":["rabbitMq"],   "address": "192.168.1.101",   "port": 15672,   "checks": [    {     "Http": "http://192.168.1.101:15672/",     "interval": "10s"    }   ]  },  {   "id":"rabbit@rabbitmq2",   "name":"RabbitMqServer",   "tags":["rabbitMq"],   "address": "192.168.1.102",   "port": 15672,   "checks": [    {     "Http": "http://192.168.1.102:15672/",     "interval": "10s"    }   ]  }  ] } 

原标题:应用.Net+Consul维护RabbitMq的高可用性

关键词:.NET

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。