我使用aws节点模块和(据我所知)已批准的方式轮询消息。
基本上概括为:
sqs.receiveMessage({
QueueUrl: queueUrl,
MaxNumberOfMessages: 10,
WaitTimeSeconds: 20
}, function(err, data) {
if (err) {
logger.fatal('Error on Message Recieve');
logger.fatal(err);
} else {
// all good
if (undefined === data.Messages) {
logger.info('No Messages Object');
} else if (data.Messages.length > 0) {
logger.info('Messages Count: ' + data.Messages.length);
var delete_batch = new Array();
for (var x=0;x<data.Messages.length;x++) {
// process
receiveMessage(data.Messages[x]);
// flag to delete
var pck = new Array();
pck['Id'] = data.Messages[x].MessageId;
pck['ReceiptHandle'] = data.Messages[x].ReceiptHandle;
delete_batch.push(pck);
}
if (delete_batch.length > 0) {
logger.info('Calling Delete');
sqs.deleteMessageBatch({
Entries: delete_batch,
QueueUrl: queueUrl
}, function(err, data) {
if (err) {
logger.fatal('Failed to delete messages');
logger.fatal(err);
} else {
logger.debug('Deleted recieved ok');
}
});
}
} else {
logger.info('No Messages Count');
}
}
});receiveMessage是我的“如果我有足够的收集消息就使用收集的消息”的函数。
偶尔,我的脚本会延迟,因为我根本得不到亚马逊的响应,例如,队列中没有消息可供使用,而不是点击WaitTimeSeconds并发送“无消息对象”,也不会调用回调。
(我写这篇文章是为了亚马逊的怪癖)
我要问的是,检测和处理这个问题的最佳方法是什么,因为我已经准备好了一些代码来停止对receiveMessage的并发调用。
这里建议的答案是:Nodejs sqs队列处理器还有防止并发消息请求查询的代码(当然,它一次只获取一条消息)
我把整件事都包好了
var running = false;
runMonitorJob = setInterval(function() {
if (running) {
} else {
running = true;
// call SQS.receive
}
}, 500);(在delete循环后运行= false (不在其回调中))
我的解决办法是
watchdogTimeout = setTimeout(function() {
running = false;
}, 30000);但是,这肯定会留下一堆漂浮的“接收者”,随着时间的推移,会留下大量的记忆?
(这份工作一直在运行,我在周五离开了它,它在星期六早上停止运转,一直挂到今天早上我手动重新开始工作为止)
编辑:我见过这样的情况:它挂起大约5分钟,然后突然收到消息,但是在20秒的等待时间内,它应该在20秒后抛出一个“没有消息”。因此,10分钟的WatchDog可能更实用(取决于业务逻辑的其余部分)。
编辑:是的,长轮询已经配置了队列端。
编辑:这是在aws-sdk的(最新)版本2.3.9和NodeJS v4.4.4下面
发布于 2018-05-02 14:19:20
我已经追踪这个(或类似的)问题几天了,下面是我注意到的:
我们能做些什么呢?这类事情的发生有许多原因,其中一些/许多事情不一定是固定的。答案是运行多个服务,每个调用receiveMessage并处理消息的到来- SQS支持这一点。在任何时候,这些服务中的一个可能会达到120秒的延迟,但是其他服务应该能够正常地继续运行。
我的特别问题是,我有一些关键的单例服务,它们不能承受120秒的停机时间。为此,我将研究以下两种方法:( 1)使用HTTP (而不是SQS )将消息推送到我的服务中;或者( 2)在每个单例( singletons )周围生成从属进程,从SQS获取消息并将它们推送到服务中。
发布于 2018-09-14 02:15:01
我也遇到了这个问题,但不是在调用receiveMessage时,而是在调用sendMessage时。我也看到了整整120秒的混乱。我也看到了一些其他服务,如消防软管。
这将我引向AWS中的这一行:
httpOptions:
timeout整数--在套接字上超时毫秒后,将套接字设置为超时。默认为2分钟(120000)。为了实现修复,我重写了我的SQS客户端的超时,该客户机在10秒后执行sendMessage超时,另一个25秒用于接收(其中我长时间轮询20秒):
var sendClient = new AWS.SQS({httpOptions:{timeout:10*1000}});
var receiveClient = new AWS.SQS({httpOptions:{timeout:25*1000}});我已经在生产中使用了一个星期,并且我注意到我所有的SQS延迟问题都已经消除了。
https://stackoverflow.com/questions/37111431
复制相似问题