SQS /任务队列作业重试计数策略？

Question

我正在使用Amazon SQS实现任务队列（但我想这个问题适用于任何任务队列），其中工作人员需要采取不同的行动，具体取决于已经重新尝试了多少次工作（移动它到不同的队列，增加能见度超时，发送警报等等）

什么是最好的方式来跟踪失败的工作计数？我想避免为作业保留一个集中的数据库：retry-count记录。我应该看看队列中的时间而不是监视过程中的时间吗？国际海事组织，这将是丑陋或不干净充其量，迭代工作，直到我找到古代..

谢谢！ Andras

Answer 1

亚马逊刚刚发布了简单的工作流程服务（swf），您可以将其视为更复杂/灵活的GAE任务队列版本。

它可以让你监控你的任务（包括听力），配置重试策略并创建复杂的工作流程。它看起来很有希望抽象出任务依赖关系，任务调度和容错（特别是异步）

结账http://docs.amazonwebservices.com/amazonswf/latest/developerguide/swf-dg-intro-to-swf.html概述。

Answer 2

我已经将SQS和SimpleDB结合在一起，取得了很好的成功。它是“集中的”，但只和SQS一样多。

每个作业都在simpleDB中获得记录，在SQS中获得任务。您可以将任何您喜欢的信息放入SimpleDB中，例如作业创建时间。当工作人员从队列中抽取工作时，它可以从simpleDB获取相应的记录以确定其历史记录。你可以看到这个工作有多大年纪，你可以看到它已经尝试了多少次。完成后，您可以将工作数据添加到SimpleDB记录（完成时间，结果，日志，错误，堆栈跟踪等等），并确认来自SQS的消息。

我更喜欢这种方法，因为它通过为失败任务提供大量调试信息来帮助诊断故障。它还允许工作人员根据工作排队的时间长短以及工作的次数等来处理工作。

它还使您能够直接查询SimpleDB并计算每个任务的平均时间，百分比故障率等。

Answer 3

还有另一种更简单的方法。通过您的消息，您可以请求ApproximateReceiveCount信息并根据您的重试逻辑。这样你就不必将它保存在数据库中，并且可以从消息本身计算出来。

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html

Answer 4

SQS代表“简单队列服务”的，在概念上是该服务的不正确的名称。 “队列”的首要特征是FIFO（先入先出），SQS缺乏这种功能。只是想澄清。

另外，Azure队列服务也缺少这个功能。对于最佳的云队列服务，请使用Azure的服务总线，因为它是一个真正的队列概念。