【问题标题】:Work Queue With Failed Job Reporting作业报告失败的工作队列
【发布时间】:2014-03-25 21:11:23
【问题描述】:

我有一个 WCF 服务(事实上它是 WCF 并不重要),我不是在寻找消息队列,而是在寻找一个异步工作队列,一旦收到请求/消息,就可以在其中放置任务。要求:

  • 必须支持持久存储,以便在服务器/服务进程失败的情况下恢复任务。
  • 支持在给定限制内重新运行失败的作业(即尝试重新运行作业最多 5 次)
  • 能够以易于查询的方式记录失败的作业调用及其参数。例如,我会在商店中查询失败的作业并收到“作业名称、参数”列表。
  • 很遗憾不能成为基于云/托管的解决方案。

我可能不想要的队列:

  • MSMQ(RabbitMQ、AMQP)。低级别,专注于消息传输。
  • 石英.NET。有上述一些,但它的错误记录设施是缺乏的。与异步工作和错误报告相比,更倾向于类似 cron 的调度。
  • .NET TPL 的默认任务计划程序。它没有持久性拥有它的进程突然停止并且不能很好地支持重新运行任务。

我想我会寻找更多类似 Celery、Resque 甚至 qless 的东西。我知道 Resque.NET 存在 (https://www.nuget.org/packages/Resque/),但不确定是否有更主流的东西,或者是否足够。

【问题讨论】:

    标签: c# .net asynchronous task-queue


    【解决方案1】:

    Amazon SQS 怎么样?您不必像使用 RabbitMQ/MSMQ 那样担心基础架构。 SQS也很便宜。上次我检查时,每 10,000 条消息是 0.01 美元。为什么要重新发明轮子?让亚马逊(或其他提供类似服务的云提供商,如 Microsoft 和 Rackspace)来做所有令人担忧的事情。

    我在生产环境中使用 Amazon SQS 来处理所有基于消息的服务。其中一些消息的作用类似于 chron 作业;外部进程在特定时间将消息排队。其中一些会立即采取行动。

    【讨论】:

    • 这些建议不错,但 SQS 看起来专注于消息而不是任务,不幸的是我也无法使用任何云/托管解决方案。
    猜你喜欢
    • 2017-02-23
    • 2014-11-19
    • 1970-01-01
    • 2018-08-16
    • 2014-03-04
    • 2018-09-11
    • 2017-09-16
    • 2018-11-24
    • 2019-07-10
    相关资源
    最近更新 更多