RabbitMQ is based on the AMQP protocol and can be passed between languages using a common protocol.
The core concept
A very powerful summary of RabbitMQ, don’t say you don’t know RabbitMQ
Type of switch, Direct, topic, fanout, headers, Wants (Whether persistence is required true required) Auto delete When the last queue bound on Exchange is deleted Exchange is deleted.
The default exchange is implicitly bound to every queue, with a routing key equal to the queue name. It is not possible to explicitly bind to, or unbind from the default exchange. It also cannot be deleted.
A very powerful summary of RabbitMQ, don’t say you don’t know RabbitMQ
In high concurrency scenarios, every DB operation is very performance consuming. We use delay queues to reduce one database operation.
What is idempotence?
If I perform an action, we can perform it 100 times, 1000 times, and the result must be the same for all 1000 times. For example, if a single thread updates an update count-1 a thousand times, the result is the same, so the update is idempotent. If a single thread updates an update count-1 a thousand times without thread-safe processing, the result may not be the same. Therefore, the concurrent update operation is not an idempotent operation. Corresponding to the message queue, even if we receive the same message, it is the same as consuming a message.
Understand the CONFIRM message confirmation mechanism
The Return message mechanism handles non-routable messages, and our producer sends the message to a queue by specifying an Exchange and a Routinkey, and we consumers listen to the queue for consumption! In some cases, if we need to listen for unreachable messages when Exchange does not exist or the specified routing key cannot be found, we need to use a Return Listener!
A Mandatory value of true enables listeners to accept unreachable messages and process them. If set to false, the broker will delete the message automatically.
What is limiting the flow at the consumer end?
Suppose we have a scenario where we have a rabbitMQ server with tens of thousands of unconsumed messages, and then we open up any consumer client and there will be a huge amount of messages sent in a flash, but our consumer can’t handle it all at once. This will cause your service to crash. There are other situations where there is a mismatch between your producer and consumer capabilities, where the producer side generates a lot of messages and the consumer side cannot consume as many messages in a high concurrency situation.
Void basicQOS(Unit prefetchSize, USHORT prefetchCount,Boolean Global).
TTL Time to Live Indicates the TTL.
Dead Letter queue: DLX, dead-letter-exchange
With DLX, when a message becomes a dead message in a queue (that is, without any consumer consumption), it can be republished to another Exchange, the DLX.
There are several ways in which a message can become dead letter:
DLX is also a normal Exchange, no different from normal Exchanges, it can be specified on any queue, actually set the attributes of a queue. When the queue is dead, RabbitMQ will automatically re-publish the message to the Exchange and route it to another queue. The ability to listen for messages in this queue for processing compensates for the immediate parameter rabbitMQ previously supported.
Dead letter queue setup
A very powerful summary of RabbitMQ, don’t say you don’t know RabbitMQ
A very powerful summary of RabbitMQ, don’t say you don’t know RabbitMQ
The Federation plugin is a high-performance plugin that transmits messages between Brokers or clusters without the need to build clusters. The two parties can use different users or virtual hosts or use different versions of Erlang or rabbitMQ. The Federation plugin can use the AMQP protocol as a communication protocol and can accept discrete transmissions.
A very powerful summary of RabbitMQ, don’t say you don’t know RabbitMQ
Federation Exchanges can be viewed as Downstream pulling messages from Upstream, but not all messages must be pulled at Downstream. An Exchange whose Bindings relationship has been explicitly defined on, that is, there is an actual physical Queue to receive messages from Upstream to Downstream. Using the AMQP protocol for inter-agent communication, Downstream will group binding relationships together and bind/unbind commands will be sent to Upstream switches. Therefore, FederationExchange only accepts messages with subscriptions.
HAProxy is a free, fast and reliable solution that provides high availability, load balancing and proxy software based on TCP (Layer 4) and HTTP(Layer 7) applications. It supports virtual hosting. HAProxy is especially useful for heavily loaded Web sites that require session persistence or seven-tier processing. HAProxy runs on current hardware and can support tens of thousands of concurrent connections. And it operates in a way that makes it easy and secure to integrate into your current architecture while protecting your Web servers from being exposed to the network.
Read and write operations in data mode, which saves a lot of CPU clock cycles and memory bandwidth
Zero-copy forwarding, zero-starting is also available on Linux 3.5 and above.
The duration of a session
Low overhead to keep timer commands, keep running queue commands, and manage polling and minimum connection queues
KeepAlived software mainly realizes high availability function through VRRP protocol. VRRP, short for Virtual Router RedundancyProtocol(Virtual Router RedundancyProtocol), is designed to solve the single point of failure (singleton failure) problem of static routes. It ensures uninterrupted network operation when individual nodes fail. Keepalived – aspect has the function of configuration management LVS, and also has the function of health check on the nodes below LVS, on the other hand, can also realize the high availability of system network services
Keepalived Failover between high availability service pairs is implemented through Virtual RouterRedundancy Protocol (VRRP). While Keepalived is working correctly, the Master node sends heartbeat messages to the standby node continuously (in multicast mode) to tell the standby node that it is still alive. When the Master node fails, it cannot send heartbeat messages. Therefore, the standby node cannot detect the heartbeat of the Master node and invokes its own takeover program to take over the IP resources and services of the Master node. When the active Master node recovers, the standby Backup node releases the IP resources and services that the active Master node takes over and restores to the original standby role
Get more Java core technology mainstream information and big factory interview questions, forward + pay attention to my private message
