rabbitmq 的心跳机制&应用

官方文档说:

If a consumer dies (its channel is closed, connection is closed, or TCP connection is lost) without sending an ack, RabbitMQ will understand that a message wasn‘t processed fully and will re-queue it

即: 如果消费者进程挂掉了(channel关闭, connection关闭,或者tcp连接丢失), 没有发回确认信息, RMQ将认为消息没有被处理完, 将重新排队等待分配。

but how?

答案是:通过心跳来监控。

官方文档在这里:https://www.rabbitmq.com/heartbeats.html

摘要如下:

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

Detecting Dead TCP Connections with Heartbeats

用心跳监控tcp连接是否丢失

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 11 minutes with default configuration on Linux, for example) to be detected by the operating system. AMQP 0-9-1 offers a heartbeat feature to ensure that the application layer promptly finds out about disrupted connections (and also completely unresponsive peers). Heartbeats also defend against certain network equipment which may terminate "idle" TCP connections.

网络故障很多种,有时很微妙(比如,丢包比率和高)。 分布式的tcp连接采取适中的时间(比如Linux默认配置大约11分钟),方便操作系统检测。AMQP 0-9-1提供heartbeat(心跳)特性来确保应用服务层及时发现已崩溃的连接(和完全无相应的peers)。 心跳机制也能保证进程不被某些网络设备给杀掉。

Heartbeat Timeout Interval

心跳超时间隔

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

心跳超时值决定了tcp相互连接的最大时间, 超过了这个时间, 该连接即被RMQ和客户端视为丢失(dead)。 这个值在客户端和服务器建立连接的时候协商确定。客户端需配才能发心跳包。 RMQ3.0及以上版本, RMQ将试着将beatheart协调为默认值(客户端可以否决这个值)。 超时时间单位为秒,默认值为60( 3.5.5发布版之前是580)。

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

心跳包每半个超时时间发送一次。 丢失了两个心跳包, 连接被认为不可抵达。 不同的客户端有不同的提示, 但tcp连接都会被关闭。 当客户端检测到RMQ节点不可抵达(根据心跳判定), 它需要重新连接(到服务器)。

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

心跳机制可以被禁用:设定超时间隔为0。

转载请注明本文源头:http://www.cnblogs.com/Tommy-Yu/p/5775852.html

谢谢!

时间: 2024-10-12 19:58:12

rabbitmq 的心跳机制&应用的相关文章

Ambari窥探分布式心跳机制

Ambari是在Hadoop大数据生态圈的基础上应运而生,Ambari的架构也借助了分布式的思想,细细品味,与Hadoop分布式架构有很多相似之处. Hadoop中单NN 与多DN的通信是借助netty封装的RPC机制实现,单Ambari server与多Agent通信则是基于restful api + json实现,rpc与rest api的争论不是本文要讨论的重点,我们追求的目标只有一个,完美实现业务需求. 心跳设计一个主要的原因是判断客户端是否在线,每隔一段时间会发送数据交互.Ambari

Linux socket编程的心跳机制总结

Linux socket编程的心跳机制总结 我写这篇文章的目的是想总结一下心跳机制的使用,因为最近两个项目的TCP通信中都使用了这个方法,感觉用法好诗比较经典的,所以拿出来与大家共享. 什么是心跳机制 心跳机制就是当客户端与服务端建立连接后,每隔几分钟发送一个固定消息给服务端,服务端收到后回复一个固定消息给客户端,如果服务端几分钟内没有收到客户端消息,则视客户端断开.发送方可以是客户端和服务端,看具体需求. 为什么要使用 我们都知道在TCP这种长连接情况下下,有可能有一大段时间是没有数据往来的,

MapReduce剖析笔记之四:TaskTracker通过心跳机制获取任务的流程

上一节分析到了JobTracker把任务从队列里取出来并进行了初始化,所谓的初始化,主要是获取了Map.Reduce任务的数量,并统计了哪些DataNode所在的服务器可以处理哪些Split等等,将这些信息缓存起来,但还没有进行实质的分配.等待TaskTracker跟自己通信. TaskTracker一般运行于DataNode之上,下面是他的声明,可见,是一个线程类: /******************************************************* * TaskT

心跳机制

网络中的接收和发送数据都是使用操作系统中的SOCKET进行实现.但是如果此套接字已 经断开,那发送数据和接收数据的时候就一定会有问题.可是如何判断这个套接字是否还可以使用呢?这个就需要在系统中创建心跳机制.其实TCP中已经为我们 实现了一个叫做心跳的机制.如果你设置了心跳,那TCP就会在一定的时间(比如你设置的是3秒钟)内发送你设置的次数的心跳(比如说2次),并且此信息不 会影响你自己定义的协议.所谓“心跳”就是定时发送一个自定义的结构体(心跳包或心跳帧),让对方知道自己“在线”. 以确保链接的

轮询与心跳机制

上一篇内容参见() 在上一篇文章中提到的缓存内网服务端会话信息中,外网服务端保存内网服务端会话的有效性以及平台上监控所有内网服务端的网络状况,模仿心跳机制实现,这里在做一点叙诉,关于思路和具体实现. 在很多的平台应用中,都有这样的需求,平台内包括多个子系统或者属于其管控范围内的其他平台,需要对这些系统进行统一的监控,来查看当前的运行状态或者其他运行信息,我们的应用也有这样的一个情况,需要再外网服务端(平台)上监控,其下运行的多个内网服务端的网络状况,查阅了写资料后确立了2种可实现的方式. 1:轮

互联网推送服务原理:长连接+心跳机制(MQTT协议)

互联网推送消息的方式很常见,特别是移动互联网上,手机每天都能收到好多推送消息,经过研究发现,这些推送服务的原理都是维护一个长连接(要不不可能达到实时效果),但普通的socket连接对服务器的消耗太大了,所以才会出现像MQTT这种轻量级低消耗的协议来维护长连接,那么要如何维护长连接呢: 在写之前,我们首先了解一下为什么Android维护长连接需要心跳机制,首先我们知道,维护任何一个长连接都需要心跳机制,客户端发送一个心跳给 服务器,服务器给客户端一个心跳应答,这样就形成客户端服务器的一次完整的握手

一种工作流心跳机制的设计

最近工作中一直和SWF(Amazon的Simple Work Flow)打交道,在一个基于SWF的工作流框架上面开发和修bug.SWF的activity超时时间是5分钟,在activity task开始执行以后,activity worker需要主动发送心跳请求告知service端:“我还活着,我还在干活”,如果出现超过5分钟(可以配置)没有心跳,SWF的service端就认为,你已经挂了,我需要把这个activity安排到别的activity worker上来执行了.借用AWS官网的一张图:

移动互联网消息推送原理:长连接+心跳机制(MQTT协议)

互联网推送消息的方式很常见,特别是移动互联网上,手机每天都能收到好多推送消息,经过研究发现,这些推送服务的原理都是维护一个长连接(要不不可能达到实时效果),但普通的socket连接对服务器的消耗太大了,所以才会出现像MQTT这种轻量级低消耗的协议来维护长连接,那么要如何维护长连接呢: 在写之前,我们首先了解一下为什么Android维护长连接需要心跳机制,首先我们知道,维护任何一个长连接都需要心跳机制,客户端发送一个心跳给 服务器,服务器给客户端一个心跳应答,这样就形成客户端服务器的一次完整的握手

服务器心跳机制

心跳机制是定时发送一个自定义的结构体(心跳包),让对方知道自己还活着,以确保连接的有效性的机制. 应用场景: 在长连接下,有可能很长一段时间都没有数据往来.理论上说,这个连接是一直保持连接的,但是实际情况中,如果中间节点出现什么故障是难以知道的.更要命的是,有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉.在这个时候,就需要我们的心跳包了,用于维持长连接,保活 什么是心跳机制? 就是每隔几分钟发送一个固定信息给服务端,服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息