RabbitMQ Federation实际应用测试加扩展构想

1. 目前问题

RabbitMQ面临三个主要问题

• Login/Logout速度慢。 6个节点的RabbitMQ集群，Login TPS只有130左右。注：这个TPS的测试基础是支持Mirror Queue，logout时不删除Queue
• 如何支持上百万的Queue(设备)。 现在测试数据是6W queue需消耗4G内存
• 支持的吞吐量。别人的数据表明，三台Node，3个Queue(做了mirror queue)，1Byte数据的情况下，可以支持4600条/秒; 未做Mirror可以达到16000条/秒。

针对以上问题，我们有长期方案与短期方案，长期方案是改”一台设备一个queue“为”一个ucas一个queue“，短期方案为Federation. 这里只介绍Federation.

2. RabbitMQ Federation

Federation简单说来就是支持MQ集群间的交流. 详细的介绍在Federated Exchanges

Federation组网的两种方式：网状模式(左下图), 环状模式(右下图)

Federation工作步骤如下：

1. 创建Upstream. 即和哪个Cluster成为federation。

• 如本集群为10.255.0.20，想和10.255.0.52组成federation.0.20上执行： rabbitmqctl set_parameter federation-upstream my-upstream '{"uri":"amqp://10.255.0.52","expires":3600000}'

2. 设置Policy。即告诉哪些exchange支持federation。

• 如想test.exchange作为federation exchange。0.20上执行： rabbitmqctl set_policy --apply-to exchanges federate-me "^test.exchange." '{"federation-upstream-set":"all"}'
• 一旦Policy生效，test.exchange会自动与0.52上的test.exchange产生federation（如果52上没有test.exchange，系统会帮忙生成一个test.exchange）
• 一个消息发送到0.20上的test.exchange，系统会自动将此消息copy一份到0.52上的test.exchange.
• 如果希望0.52上test.exchange也federate到0.20,只需要在0.52上执行上面的upstream和policy.

3.优化方案

上面我们描述到，一个RabbitMQ集群为了支持更多的Queue，需要增加内存，增加机器，但机器增加会导致Login/Logout变得更慢。所以我们引入了sub-cluster概念。 为了描述的方便，这里定义由多个sub-cluster组成一个RabbitMQ Cluster

• Sub-cluster由至少两台Node组成
• 每个Sub-cluster的exchange相同，但queue不同
• Sub-cluster内的queue采用mirror queue进行HA
• Sub-cluster之间通过Federation进行通讯

如下图：

优化方案为：同一个Site的用户可以分配到不同Sub-Cluster。简单的Queue分布例子如下：

方案中需要解决的问题

我们知道要去Consume某个RabbitMQ集群Queue中的消息，需要连接到此集群才行，不能跨集群进行consume(除非做了Federated Queue), 因此我们需要解决如下问题

• 用户如何分配到哪个Sub-cluster. UCC, UCAS和守护进程都需要。
• 1:1消息如何发送
• Org组织通知消息如何发送
• Group消息如何发送
• 集群如何添加新的sub-cluster

例子, 三个Sub-clusters, 每个sub-cluster由两台Node组成，Queue采用Mirror Queue

• Sub-cluster 1 VIP:10.255.0.1
• Sub-cluster 2 VIP:10.255.0.2
• Sub-cluster 3 VIP:10.255.0.3

3.1 用户如何分配到哪个Sub-cluster

方法就是取模。HASH(用户ID)/3，假设取模为2, 则连接的MQ VIP为10.255.0.2

3.2 1:1消息如何发送

获取RabbitMQ VIP，先通过取模获的MQ VIP. 用户ID可以是消息目标用户的ID，也可以是消息发送者的ID。其他逻辑不变。

3.3 Org组织通知消息如何发送

获取RabbitMQ VIP，先通过取模获的MQ VIP. 由于目标用户太多，所以用户ID为消息发送者的ID.其他逻辑不变。

3.4 Group消息如何发送

用户ID为发送者的ID。其他逻辑不变。

3.5 集群如何添加新的sub-cluster

由于采用了取模方式定位MQ VIP, 所以没有更好的办法，通用的办法就是Active-Passive模式。

• 1. 老的Active RabbitMQ Cluster为4个sub-cluster, 现在需要两个新的sub-cluster
• 2. 创建Passive RabbitMQ Cluster，包含6个sub-cluster
• 3. 周末凌晨某个时间点，刷新sub-cluster，RabbitMQ Cluster从Active集群切换到Passive集群，即Passive集群变成Active集群。
• 4. 切断UCAS与老的RabbitMQ Cluster的连接，更新UCAS配置中RabbitMQ的配置
• 5. 清空Memcached数据以便session过期，用户重新登录
• 6. 此集群的用户陆续重新登录
• 7. 老的RabbitMQ Cluster机器回收给其他集群使用。

之所以不采用在老的RabbitMQ Cluster动态添加节点的方式，原因是：

• 分配不均衡。由于是HASH方式，这样的后果就是：老的Sub-cluster接近上限，新加入的sub-cluster依旧吃不饱
• 容易造成服务拓机。新节点的加入，操作上容易出现失误，一旦需要重启RabbitMQ Node(10W Queue的RabbitMQ节点的恢复时间超过一个小时)，造成UCC服务长时间拓机。

4. 性能评估

4.1 Login

理论上登录的TPS公式为：130 * N, 注：N为sub-cluster个数 假如我们设置sub-cluster为3， 则登录可以达到400 TPS

4.2 支持的Queue

只和机器个数与内存有关。为了支持100w用户，其中100w个mobile设备，20w个PC，则总计的Queue为120w，mirror queue后为240w，需要的内存为240w/6w * 4G = 160G。考虑内存50%为一个报警阀值，则需要320G内存，每个机器16G内存，总共需要20台虚拟机。 所以，支持100W用户，虚拟机为16G，需要20台；虚拟机为32G，为10台。

4.3 吞吐量

因为Org通知消息一般非常非常少，对系统的压力可以忽略。所以整个RabbitMQ集群的吞吐量，可以简单认为是 ：单台集群吞吐量 * N