RABBITMQ's heartbeat mechanism & application

official documentation says:

If A consumer dies (its channel was closed, connection is closed, or TCP connection are lost) without sending an ACK, Rabbit MQ would understand that a message wasn ' t processed fully and would re-queue it

That is: If the consumer process hangs (channel off, connection off, or TCP connection is lost ), no acknowledgement is sent back, RMQ will think that the message has not been processed and will be queued for allocation again.

But how ?

The answer is: monitor through the heartbeat.

official documentation is here: https://www.rabbitmq.com/heartbeats.html

The summary is as follows:

=====================================================================

Detecting Dead TCP Connections with heartbeats heartbeat monitoring TCP connection is missing introduction introduction

Network can fail in many ways, sometimes pretty subtle (e.g. high ratio packet loss). Disrupted TCP connections take a moderately long time (about one minutes with the default configuration on Linux, for example) To is detected by the operating system. AMQP 0-9-1 offers a heartbeat feature to ensure so the application layer promptly finds out about disrupted con Nections (and also completely unresponsive peers). Heartbeats also defend against certain network equipment which may terminate "idle" TCP connections.

There are many kinds of network faults, sometimes very subtle (for example, packet loss ratio and high). Distributed TCP connections take a modest amount of time (for example, the Linux default configuration of about 11 minutes) for easy OS detection. AMQP 0-9-1 provides the Heartbeat (heartbeat) feature to ensure that the application service layer discovers a crashed connection (and no corresponding peers at all) in time. The heartbeat mechanism can also ensure that the process is not killed by certain network devices.

Heartbeat timeout interval heartbeat timeout interval

The heartbeat timeout value defines after what period of time the peer TCP connection should is considered dead by rabbitm Q and client libraries. This value was negotiated between the client and RabbitMQ server at the time of connection. The client must is configured to request heartbeats. In RabbitMQ versions 3.0 and higher, the broker would attempt to negotiate heartbeats by default (although the client can s till veto them). The timeout is in seconds, and default value is (580 prior to release 3.5.5).

The heartbeat timeout determines the maximum time that TCP is connected to each other, and the connection is considered lost by RMQ and the client (dead). This value is negotiated when the client and server establish a connection. The client needs to be equipped to send a heartbeat packet. RMQ3.0 and above, RMQ will try to reconcile the Beatheart to the default value (the client can veto this value). The time-out is in seconds, and the default value is 60 (before the 3.5.5 release is 580).

Heartbeat frames is sent about every timeout/2 seconds. After a missed heartbeats, the peer is considered to be unreachable. Different clients manifest this differently but the TCP connection would be closed. When a client detects this RabbitMQ node is unreachable due to a heartbeat, it needs to re-connect.

Heartbeat packets are sent once per half time out . Two heartbeat packets have been lost and the connection is considered unreachable. Different clients have different prompts, but TCP connections are turned off. When the client detects that the RMQ node is unreachable (as determined by the heartbeat), it needs to reconnect (to the server).

Heartbeats can disabled by setting, the timeout interval to 0.

The heartbeat mechanism can be disabled: The set timeout interval is 0.

Reprint please indicate the source of this article: http://www.cnblogs.com/Tommy-Yu/p/5775852.html

Thank you!

RABBITMQ's heartbeat mechanism & application