8


我将制作集成亚马逊云服务的 Rails 应用程序。

  • 我已经探索了亚马逊的 SNS 服务，它提供了我不想做的公共订阅设施。我只想通知特定的订阅者。例如，如果我在一个主题中有 5 个订阅者，那么通知应该发送给特定的订阅者。
  • 我还探索了亚马逊的 SQS，我必须在其中编写一个轮询器来监控消息队列。SQS 也有一个锁定机制，但问题是它是分布式的，因此有可能从另一个队列副本中获取相同的消息以进行处理。

我想知道可能的方法是什么。

4

1 回答 1

15

SQS 听起来像你想要的。

您可以运行多个竞争队列中消息的“工作”进程。每条消息只被消费一次。您提到的“锁定”/超时背后的逻辑如下：如果您的一个工作人员在下载消息后但在处理它之前死亡，那么您希望该消息最终超时并重新下载以进行处理在另一个节点上。

是的，SQS 建立在轮询模型之上。例如，我有许多用例，在这些用例中，我使用每分钟的 cron 作业来轮询队列中的新消息并对找到的任何消息采取行动。这种模式构建起来非常简单，并且为一堆用例创造了奇迹——一个方便的小“客户端”脚本，它将消息推送到队列中，而 cron 激活的脚本将在一分钟左右的时间内处理该消息。

如果您的消息模式非常稀疏（例如，一天只有几条消息），那么在队列为空时不断轮询似乎很浪费。这几乎无关紧要。

我最初的计算是，一个微小的 cron 作业每月需要花费 0.04 美元（现在是 0.02 美元）。从那时起，SQS 添加了“长轮询”功能，通过每 20 秒发送 1 条“长轮询”消息来轮询空闲队列，您可以在处理新消息时实现亚秒级延迟。另外，他们将价格降低了 50%。因此，每月有 131k 条消息（约 0.06 美元），稍微贵一点，但具有近乎实时的请求处理能力。

请记住，我描述的一个微小的 cron 作业在请求负载（30d*24h*60m * 1c / 10k msgs）上仅花费约 0.04 美元/月。因此，在一个微小的剪辑中，成本不应该是一个真正的问题。即使每秒轮询一次，价格也只上涨到 2.59 美元/月，这并不完全是银行破坏者。

但是，可以使用接收 SNS HTTP 消息的 Web 服务来避免频繁轮询。这样的架构将按如下方式工作：客户端将消息推送到 SNS，SNS 将消息推送到 SQS 并将 HTTP 请求路由到您的 Web 服务，触发它排空队列。您仍然希望每小时或每天轮询队列，以防 HTTP 请求被丢弃。最后，我不确定我是否能想到任何真正证明这种复杂性的场景。我宁愿每月支付 0.04 美元，让一个肮脏的简单 cron 工作轮询我的队列。

于 2011-05-16T19:15:27.047 回答