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

This article is to share with you about the differences between the four cluster architectures in Java Rabbitmq. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Four cluster architectures of Rabbitmq

1. Active and standby mode

two。 Remote mode

3. Mirror mode

4. Multi-activity mode

Active and standby mode

Active / standby mode: warren rabbit nest one master, one standby master node if the slave node provides services and Activemq uses zk as the master / standby

Active / standby mode-"HaProxy configuration"

Listen rabbitmq_cluster bind 0.0.0.0mode tcp 5682 # configure tcp mode mode tcp # simple polling balance roundrobin # primary node server bhz76 192.168.11.78 virtual 5672 check inter 5000 rise 2 fall 2 server bhz76 192.168.11.79 rise 2 fall 2 # standby node remote mode

Remote mode remote communication and replication can achieve dual active mode, referred to as Shovel mode configuration trouble is not much used now

The so-called Shovel means that we can copy messages in different data centers and interconnect two mq clusters across regions.

Step1 1.0 starts the RabbitMq plug-in rabbitmq-plugins enable amqp_client rabbitmq-plugins enable rabbitmq_shovel2. 0 create rabbitmq.config file touch / etc/rabbitmq/rabbitmq.config

Mirror mode

The classic thing about cluster mode is that Mirror mirroring mode ensures that 100% data is not lost.

It is most used in practical work and the implementation of clustering is very simple. Generally speaking, large Internet companies will use this way to build this kind of mirror cluster model.

Mirror Mirror queue

High reliability-"data synchronization -" elang switch-3 nodes

Disadvantages: no guarantee of horizontal expansion

Multi-activity mode

This mode is also the mainstream mode to realize remote data replication, because the configuration of Shovel mode is more complex, so generally speaking, remote clusters are implemented using this dual-active or multi-active model.

This model requires a federation plug-in that relies on RabbitMq to achieve a continuous and reliable Amqp data communication multi-active mode. The actual configuration and application is very simple.

The RabbitMq deployment architecture adopts a dual-center model and multi-center, so if you deploy a set of RabbitMq cluster client center RabbitMq services in two or more sets of data centers, in addition to providing normal message services for the business, you also need to achieve partial queue message sharing between centers.

Federation plug-in

The Federation plug-in is a high-performance plug-in that transmits messages between Brokers without building Cluster. The Federation plug-in can transfer message connections between Brokers or Cluster. Both parties can use different users and virtual hosts plug-ins, or they can use different versions of RabbitMq and Erlang Federation plug-ins to receive disconnected transmissions using AMQP protocol communication.

Federation Exchanges can be seen as Downstream actively pulling messages from Upstream, but not all messages must be Exchange with clearly defined Bindings relationship on Downstream, that is, there is an actual physical Queue to receive messages before they are combined from Upstream. Bind / unbind commands are sent to the Upstream switch, so Federation Exchanges only receives messages with subscriptions.

Thank you for reading! This is the end of the article on "what is the difference between the four cluster architectures in Java Rabbitmq". I hope the above content can be helpful to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.