在基于队列的分发系统中进行限制以管理SLA

时间:2015-11-04 21:05:06

标签: message-queue scalability distributed amazon-sqs

我的系统由一组服务组成,这些服务使用SQS队列来传达要处理的任务。我们现在为一部分客户(A组)生成一个工件,但是也希望开始为所有其他客户(B组)生成,增加十倍。流程如下:1。来自上游依赖的新输入,我们在工作队列中接收消息2.从队列中抓取任务,进行一些处理,将输出放在另一个服务的输入队列中3.重复

我们没有能力在每次收到新输入时生成新工件,所以我想通过将输入速率与我们的消耗率解耦来解决这个问题。我们仍然希望继续按照他们目前收到的节奏(每6小时)为A组生成工件。每天刷新一次B组的工件就足够了。如果我们可以控制自己的刷新频率,我们就可以以我们知道可以支持的速率消耗输入。

由于我们基于队列的系统没有跟踪任何类型的状态,我正在考虑使它们更有状态 - 当我们最后一次尝试生成工件时记录,并且没有生成新的版本如果没有6小时(A组)或24小时(B组)。问题是不同的帐户有非常不同的处理时间(从几分钟到超过12小时),并且因为这些调用是异步的,我们目前无法知道是否/何时生成工件 - 这是最好的努力,如果是特定运行失败我们等待下一组输入并尝试使用新输入生成。

实际上,我将实现自己的限制并决定何时处理消息与删除消息。限制系统的输入不是一种选择,因为在检查其内容之前删除请求可能会导致我们错过消息并错过我们的SLA。

这是一个思考问题的好方法吗?

1 个答案:

答案 0 :(得分:0)

尝试再解析一下你的问题,但这是我想到的。我想到的是,您真正想要编排一堆子任务来生成最终的工件。您可以将其视为工作流程。

由于您已经在使用SQS,我想您已经在AWS中,所以您可以考虑使用简单工作流程(SWF)来帮助您管理它。您可以使用它来维护不同作业的某些状态,而不是尝试构建自己的状态机'使用SQS。

当然,如果您要坚持使用SQS,您甚至可以考虑创建一个完整的单独队列,您可以像消息总线上的控制平面一样使用它。再想一想,这可能太乱了。