rabbitmq

OpenStack RPC Queues

说明

文本分析的 OpenStack 版本为 Kilo (2015.1.0),不过社区关于 RPC 架构的设计十分经典,在四年多的时间内基本没有变化,所以有必要在此记录。

表格有四列:

  • Exchange: 队列的 Exchange,后缀是 fanout 的 Exchange 为 fanout 类型;标记(topic)的为 topic 类型。
  • Queue: 队列的名字。
  • Routing Key: 队列的 Routing Key,一般和队列名一样。但是 fanout 的 routing key 比较特殊,为去掉 fanout_{uuid} 后的字符串。
  • Service: 申明此队列的服务,一般是
查看详细

RabbitMQ Cheat Sheet

临时修改内存限制

rabbitmqctl set_vm_memory_high_watermark 0.6

设置 TTL

设置全局 TTL 为 24 小时,文档在这里!注意 3.X 之后才支持。
其中 priority 值越高,优先级越大,默认是 0。

sudo rabbitmqctl set_policy TTL ".*" '{"message-ttl":86400000}' --apply-to queues
sudo rabbitmqctl set_policy ttl-24h ".*" '{"message-ttl":86400000}' --apply-to queues  --priority 100
sudo rabbitmqctl list_policies

组件集群

版本 < 3.X

sudo rabbitmqctl stop_app
sudo rabbitmqctl cluster rabbit@hostname_of_master
sudo
查看详细

OpenStack Tricks And Reminders

OpenStack 是一个庞大的项目,包含越来越多的子项目,安装、配置、维护也越发复杂。和任何开源项目一样,总会有各种各样的坑在等着新人去挖掘。文本记录着生产环境中遇到的 OpenStack 各种奇奇怪怪的问题,这些问题往往不成体系,无需单独撰文,所以零散的记录在这里。

连接数

生产环境中使用的是 MySQL, RabbitMQ作为外部依赖,如果没有做好集群,最好配置完善的监控,保证不会达到这些服务的连接数上限,否则会突然发现… 查看详细

OpenStack Neutron Fanout 队列残留

在生产环境中遇到 RabbitMQ 暂停服务,生产者无法生产消息,消费者也消费不了消息。按照经验判断 RabbitMQ 暂停服务要么是磁盘,要么是内存达到 RabbitMQ 的上限。事实证明确实是内存达到上限。删除没用的消息,队列,搞定。

不过问题并没有根本解决,RabbitMQ 作为消息的Broker,在 OpenStack 架构中,它只是消息的代理人,生产者生产消息,消费者消费消息,正常情况下不应该有消息堆积,或者队列残留。… 查看详细

Nova配置高可用RabbitMQ

概述

Havana的nova已经支持使用RabbitMQ的高可用队列。此文章介绍高可用队列的特点,如何配置nova使用高可用队列,及测试结果。

高可用队列

RabbitMQ的高可用首先要用到集群模式(Cluster),在集群中的所有RabbitMQ实例互相感知对方的存在。RabbitMQ的高可用为Active/Active模式,多个RabbitMQ实例相互之间做镜像,即一条消息发给任意一个RabbitMQ实例后,RabbitMQ会负责将此消息同步到集群中的所有节点。如此RabbitMQ的客户端可以有两种使用方式:一种在RabbitMQ前部署Haproxy,向客户端隐藏集群的具体地址。另一种直接由客户端选择任意一个RabbitMQ实例连接,如果发生连接中断则选择另外一个MQ实例。… 查看详细