0

我用ajax上传照片，操作和上传到s3需要很多时间。我听说最好在后台完成这些任务。我的应用需要等待照片上传。但是如果我选择后台方式，那么我将需要使用 websockets 或重复 ajax 来检查结果（链接到 s3）（我对此不满意）。为什么在控制器（前台）中进行硬计算太糟糕了？现在我使用 Torquebox(Jruby) 并且据我所知它具有完美的并发性。这是否意味着等待上传到 s3 不会占用资源并且一切正常？请在我的情况下写下背景/前景的利弊。谢谢！

4

1 回答 1

1

在向第三方服务发出网络请求时阻止 Web 请求处理程序通常被认为是不好的做法。如果该服务变得缓慢或不可用，这可能会阻塞您的所有 Web 进程，无论您使用的是什么 ruby​​。这就是您所说的“前景”。

本质上这是您当前设置的流程（在前台）：

  1. 用户在您的站点上上传图像，您所需的控制器收到请求。
  2. 您的控制器向 s3 发出同步请求。这是一个阻塞请求。
  3. 您的控制器正在等待
  4. 您的控制器正在等待
  5. 您的控制器（继续）等待
  6. 最后，（这并不能保证）您会收到来自 s3 的响应，并且您的代码会继续并呈现您给定的视图/json/text/etc。

显然，步骤 3-5 对您的服务器来说是个坏消息，正如我之前所说，这个工作/线程/进程（取决于您的 ruby​​/rails 服务器框架）将被“暂停”，直到收到来自 s3 的响应（其中可能永远不会发生）。

这是与后台作业相同的流程，前端有一些 javascript 帮助用于通知：

  1. 用户在您的站点上上传图像，您所需的控制器收到请求。
  2. 您的控制器创建一个新线程/进程来向 s3 发出请求。这是一种非阻塞方法。您在引用您的 s3 图像 src 的记录上设置了一个标志，例如 completed: false 并且您的代码很好地继续到 step 3。您的新线程/进程现在将等待来自 s3 的响应，并且当 s3 响应时，您将“已完成”标志设置为 true。
  3. 您呈现您的视图/json/text/etc，并为这个请求固有地释放您的工作人员/线程/进程......好消息！

现在来看看有趣的前端内容：

  1. 您的客户端收到您的响应，触发您的前端 javascript 以启动一个类似 setInterval 的重复函数，该函数每 3 秒“ping”一次您的服务器，您的后端控制器检查您设置的“完成”标志较早为真，如果是，则响应/呈现为真。
  2. 您的客户端 javascript 收到您的响应并继续 ping（直到您指定它应该放弃）或停止 ping，因为您的应用程序响应为 true。

我希望这能让你走上正确的道路。我认为为这个答案编写代码是劣等的，因为您似乎在寻找利弊。对于实际的实现想法，我会研究以下内容：

  • sidekiq非常适合解决此处描述的后台作业问题。它将处理创建新进程，您可以在其中向 s3 发出请求。
  • 这是一个出色的railscast，它将帮助您更好地理解代码。
于 2015-02-23T03:52:22.223 回答