ruby - 在异步作业中使用“睡眠”是否合理？

Question

假设我有一个场景，我正在处理工作人员的后台作业。它只是接收托管在远程 CDN 上的文件（图像、视频、pdf、..）的 URL，并且 worker 的工作如下：

1. 对内存中文件内容的一些处理
2. 然后调用第 3 方 API 来检索签名的有效 URL，以便将内容上传到同一第 3 方。
3. 将内容上传到第 3 方 API – 响应包含唯一的文件 ID
4. 通过 3rd 方 API向用户发送一条消息，其中包含之前收到的唯一文件 ID

现在，问题在步骤（3）和（4）之间。这里的限制是，在我们实际发送包含我们刚刚上传的文件 ID 的消息（步骤 4）之前，第 3 方 API 需要几秒钟来处理文件（步骤 3）。

这里的另一个假设是我需要确保所有 4 个步骤一次执行，例如，没有任何部分失败的机会。

可能的方法

• 最天真的方法是sleep 5在步骤 (3) 和 (4) 之间使用，这可能会造成伤害/严重失败，因为我不确定第 3 方 API 需要多少秒来处理，但根据我的试验，5秒睡眠似乎还不错。

• 我可以对步骤 (3) 进行 3 次（或 X）次进程内指数重试，从第 3 方捕获异常并在步骤 (3) 成功时尝试执行步骤 (4) – 这就是我所拥有的现在，它工作正常。

• 我也许可以使用作业调度程序或 ruby​​ 并发库以延迟方式执行步骤 (4)。我不喜欢这条路，因为感觉它有利于复杂性。

这段逻辑是用 Ruby 构建的，虽然这个问题可能不是非常特定于 Ruby 并且可以适用于其他语言，但我想听听 Ruby 人的想法。

标签： rubyconcurrencyjobsworkerdistributed-system

Answer 1

您链接到的API 文档说：

注意力！服务器需要一些时间来处理上传的文件。文件应在短暂超时（几秒钟）后发送到聊天室

我通常会建议不要使用这种性质的东西，但是由于您的供应商特别说“超时”，sleep因此是最好的选择。