【问题标题】:Message queuing per tenant每个租户的消息队列
【发布时间】:2018-11-01 17:24:18
【问题描述】:

我有一个 API,其中客户端异步提交作业,可以轻松地将其分为许多较小的任务。有时我们收到的作业比我们实时处理的要多,因此我想为每个客户端设置一个作业队列,以便我可以在客户端之间循环处理作业。这样一来,如果一个客户提交了一项巨大的工作,来自其他客户的微小工作就不必等待巨大的任务。

对于我的具体情况,每个任务只处理一次很重要。

我一直在研究 RabbitMQ,但我还没有找到一种方法让消费者(在本例中为处理器)订阅所有匹配模式的队列,例如队列可以订阅交换。

Kafka 似乎有我想要的客户端分区,但似乎没有提供足够的确定性来保证任务将被交付一次。多个消费者拥有不同偏移量的能力进一步放大了这一点。

是否可以设置消息队列代理来执行我所描述的操作?

【问题讨论】:

    标签: message-queue scheduling


    【解决方案1】:

    在您的情况下,无法保证只处理一次。当任务处理完成,但由于硬件故障没有发送确认时,消息系统应该怎么做?它可以丢弃消息(实际上丢失了客户请求)或重新发送消息(仅违反一次)。应该有一种方法来检查请求是否已被处理。它将允许您使任务处理具有幂等性。

    顺便说一句,我认为队列不适合您的用例。查看Cadence Workflow,它将为您提供很多功能和开箱即用处理的可见性。

    与使用队列进行任务处理相比,Cadence 提供了许多优势。

    • 内置指数重试,无限期间隔
    • 故障处理。例如,如果在配置的时间间隔内两次更新都无法成功,它允许执行通知另一个服务的任务。
    • 支持长时间运行的心跳操作
    • 能够实现复杂的任务依赖。例如,在发生不可恢复的故障时实现调用链或补偿逻辑 (SAGA)
    • 提供对当前更新状态的完整可见性。例如,当使用队列时,您知道队列中是否有一些消息,并且您需要额外的数据库来跟踪整体进度。使用 Cadence 记录每个事件。
    • 能够取消正在进行的更新。
    • 分布式 CRON 支持

    请参阅 the presentation,了解 Cadence 编程模型。

    【讨论】:

      猜你喜欢
      • 2012-01-21
      • 2020-12-12
      • 2015-08-22
      • 1970-01-01
      • 1970-01-01
      • 2016-02-15
      • 2019-12-24
      • 2018-06-17
      • 1970-01-01
      相关资源
      最近更新 更多