Shulou(Shulou.com)06/01 Report--

How to carry out RabbitMQ Federation plug-in analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Before the article begins, let's introduce the basic concepts of the federal mechanism. The implementation of the federation mechanism depends on the Federation plug-in of RabbitMQ. The main goal of this plug-in is to enable RabbitMQ to seamlessly deliver messages in multiple Broker nodes or clusters.

The Federation plug-in allows multiple switches and queues to federate. A federated switch or a federated queue accepts upstream (switches and queues on other Broker) messages. The federated switch can route messages originally sent to the upstream switch (upstream exchange) to a local queue; the federated queue allows a local consumer to receive messages from the upstream queue (upstream queue).

Federation switch

Let's assume a scenario where the BrokerA service is deployed in Shanghai and the BrokerB service is deployed in Beijing. The network delay for ClientA from Shanghai to send messages to BrokerA's exchangeA is very small, but Beijing's ClientB will face the problem of network delay when sending messages to BrokerA's exchangeA. The Federation mechanism can help us solve this problem.

First of all, establish an one-way Federation Link with BrokerB in Beijing on BrokerA's exchangeA. In this case, the Federation plug-in will set up a switch with the same name (configurable, default) on BrokerB, and will also set up an internal switch federation:exchangeA- > BrokerB (where Broker is the cluster name) to bind with the same binding build. At the same time, the Federation plug-in will create a federation:exchangeA- > BrokerB (BrokerB is the cluster name) and bind the internal switch federation:exchangeA- > BrokerB to the queue.

The Federation plug-in establishes an AMQP connection between queue federation:exchangeA- > Broker B and the switch exchangeA in BrokerA to consume the data in queue federation:exchangeA- > Broker B in real time. These operations are internal, and for external business clients, the Federation link is established between BrokerA's exchangeA and BrokerB's exchangeA.

At this time, ClientB can send a message to the exchangeA of BrokerB with less network delay, and the message will be correctly routed to the exchangeA in BrokerA. Through the Federation plug-in, we can send messages to Broker nodes that belong to different regions from the client with less network delay.

"max_hops=1" means that a message can be forwarded up to 1 times.

Default switches (a switch named "" is created by default under each vhost) and internal switches, which cannot be used with Federation features.

Federal queue

The queues queue1 and queue2 were originally in broker2, but were configured as federated queue and broker1 as upstream due to some requirement. The Federation plug-in creates queues queue1 and queue2 with the same name on broker1, and creates two one-way independent Federation link with queues queue1 and queue2 in broker2. When a consumer ClientA connects to broker2 and consumes messages in queue queue1 (or queue2) through Basic.Consume, if there are several messages accumulated in queue queue1 (or queue2), then ClientA consumes these messages directly, and queue1 (or queue2) in broker2 does not pull messages from queue1 (or queue2) in broker1. If there is no message accumulation in the queue queue1 (or queue2) or the message is consumed, it pulls the message (if any) in the upstream queue queue1 (or queue2) in broker1 through Federation link, stores it locally, and then consumes it by the consumer ClientA.

Unlike federated exchange, a message can be forwarded indefinitely between federated queues. Two queues can be federated queues for each other.

If the two queues are federated queues, the messages in the queue will not only be consumed, but also be transferred to the party with excess consumption power. If this "excess consumption power" is switched back and forth between broker1 and broker2, then the consumption will also be forwarded back and forth in queue queue in broker1 and broker2.

Federation queue can only use Basic.Consume for consumption and is not transitive.

Federation usage

The Federation plug-in is available in the RabbitMQ release package by default. Execute the rabbitmq-plugins enable rabbitmq_federation command to enable the Federation function. The rabbitmq-plugins enable rabbitmq_federation command opens the amqp_client plug-in at the same time. If you want to open the Federation management plug-in, you need to execute the rabbitmq-plugins enable rabbitmqfederation_management command.

When you need to use the Federation function in the cluster, all nodes in the cluster should turn on the Federation plug-in.

In the previous chapter, we built a 3-node rabbitmq cluster (suppose in Shanghai), we are building a two-node cluster (suppose in Beijing), this reader can build it on his own. In our first cluster, there is an exchangeA and queueA under the default vhost. A client in Beijing needs to send a message to exchangeA. In order to reduce network latency, we use the federated mechanism to use the cluster in Beijing as an upstream resource. Let's talk about configuration.

First, configure Federation Upstreams in the Shanghai cluster, as shown below:

Name: defines the name of this upstream. Required.

Uri: defines the AMQP connection of upstream. What we set here is amqp://upstreamer:123456@rabbit111:5672 (here is a node address for a Beijing cluster), in the format amqp://username:password@host:port.

Prefetch count: defines the number of messages cached within Federation, that is, the number of messages cached after receiving upstream messages and before sending them downstream.

How many seconds do you have to wait to start re-establishing the connection after Reconnect delay:Federation link is disconnected for some reason.

Acknowledgement Mode: defines the message acknowledgement method for Federation link. There are three kinds: on-confirm, on-publish and no-ack. The default is on-confirm, which means that the message acknowledgement is sent to the upstream after receiving the downstream confirmation message (waiting for the downstream Basic.Ack). This option ensures that the message will not be lost in the event of network failure or Broker downtime, but it is also the slowest option to process. If set to on-publish, it means that the message is sent downstream (and needs to wait for the downstream Basic.Ack) before sending a message acknowledgement to the upstream. This option ensures that the message will not be lost in the event of a network failure, but does not guarantee that the message will not be lost if the Broker goes down. No-ack says there is no need for message confirmation, and this option is the fastest to process, but it is also the most likely to lose messages.

Trust User-ID: sets whether Federation uses the "Validated User-ID" feature. If set to false or not, Federation ignores the user_id property of the message; if set to true, Federation only forwards messages whose user_id is any valid upstream user.

Exchange: specify the name of upstream exchange, which is the same as federated exchange by default. Here we specify beijingExchange.

Max hops: specifies the maximum number of jumps in the Federation link before the message is discarded. The default is 1. Note that even if the max-hops parameter is set to a value greater than 1, the same message will not appear twice in the same Broker, but it may be replicated in multiple nodes.

Expires: specifies the timeout of the upstream queue corresponding to the federated queue after the Federation link is disconnected. It defaults to "none" and indicates that it is not deleted. It is measured in ms. This parameter is equivalent to setting the x-expires parameter of a normal queue. Setting this value can prevent producers from sending messages to the upstream exchange in the Beijing cluster after the Federation link is disconnected, and these messages cannot be forwarded to the cluster in Shanghai and consumed, resulting in a large number of messages in the upstream exchange.

Message TTL: set for the upstream queue corresponding to federated queue, which is equivalent to the x-message-ttl parameter of a normal queue. The default is "none", which means that the message does not time out.

HA policy: set for the upstream queue corresponding to federated queue, which is equivalent to the x-ha-policy parameter of a normal queue. The default is "none", which means that the queue does not have any HA.

Queue: the name of the execution upstream queue, which has the same name as federated queue by default

After configuring Federation Upstreams, define a Policy to match the switch exchangeA, and use the previous Federation Upstreams configuration, as shown below: when the policy is configured, Federation will create a beijingExchange and Federation link on the cluster in Beijing, as shown below:

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.