我正在尝试使用 Node.js 在 Azure功能中向我的 Azure存储队列添加约6000条消息。
我已经尝试了多种方法来做到这一点,现在我把它包装好了
Promise
中的QueueService method并使用Bluebird通过Promise.map
并发约50来解决6000个承诺。
const addMessages = Promise.map(messages, (msg) => {
//returns a promise wrapping the Azure QueueService method
return myQueueService.addMessage(msg);
}, { concurrency: 50 });
//this returns a promise that resolves when all promises have resolved.
//it rejects when one of the promises have rejected.
addMessages.then((results) => {
console.log("SUCCESS");
}, (error) => {
console.log("ERROR");
});
我的QueueService是使用ExponentialRetry
政策创建的。
我使用此策略的结果好坏参与:
我是否遗漏了某些内容,或者我的通话有时需要2分钟才能解决,有时甚至超过10分钟?
将来,我可能不得不添加大约100.000条消息,所以我有点担心我现在的不可预知的结果。
在Node (在Azure功能中)中添加大量邮件的最佳策略是什么?
修改
不确定我是如何错过这一点的,但是将我的消息添加到存储队列的一种非常可靠的方法是使用我的Azure功能的队列输出绑定:
使我的代码更容易!
for (var i = 0; i < messages.length; i++) {
// add each message to queue
context.bindings.outputQueue.push(messages[i]);
}
EDIT2:
我将以大约1000个批量拆分我的邮件,并将这些批次存储在 Azure Blob存储中。
每次添加新blob时都可以触发另一个Azure函数,此函数将一次处理1000个消息的排队。
这应该让我的排队更加可靠和可扩展,因为我尝试通过输出绑定向队列中添加20.000条消息,并在5分钟之后接收Azure功能超时,只能处理大约15.000条消息。
答案 0 :(得分:1)
是什么触发了此功能?我建议,而不是让一个函数添加所有这些消息,就是扇出并允许这些函数通过限制他们正在进行的工作量来扩展并更好地利用并发性。
在我上面提出的建议中,您已经拥有处理现有触发器的功能,今天将工作排队,然后由另一个执行添加操作的实际工作的功能处理(很多)到队列的消息数量较少。您可能需要使用这些数字来查看哪些功能可以根据您的工作负载正常运行,但是这种模式可以让这些功能更好地扩展(包括跨多台计算机),更好地处理故障并提高可靠性和可预测性。
例如,您可以在排队的消息中显示消息数以触发工作,如果您希望将1000条消息作为最终输出,则可以排列10条消息,指示您的&#34; worker&#34;用于每个添加100条消息的功能。我还建议每个功能使用更小的数字。
我希望这有帮助!