0

这是一个关于哪种方案是解决服务器端繁重情况但为用户提供响应式 UI 的更智能方法的建议。

设置； 我的系统由两个服务组成（用节点编写）；一个前端服务，它监听来自用户的请求和一个后台工作人员，它执行繁重的工作并且不会在 1-2 秒内完成（例如，视频转换、图像大小调整、gzipping、蜘蛛等）。用户通过 WebSockets（和正常的 POST 请求）连接到前端服务。

情景1； 当用户例如。上传视频，前端服务只做一些简单的检查，以用户的名义创建一个工作给后台工作人员处理并直接以状态200响应。稍后工作人员看到它的工作，完成工作并完成工作。然后它会找到用户连接的套接字（如果有的话）并发送“嘿，工作完成”，其中包含与视频转换作业相关的数据（url、长度、比特率等）。

  • 我看到的优点：成功上传的快速用户反馈（例如，可以隐藏 ProgressBar）
  • 我看到的缺点：用户将得到一个虚假的“成功”响应，没有要处理/显示的数据，并且无论如何都需要等到工作完成。

情景2； 与场景 1 类似，但前端服务不会以状态 200 响应，而是订阅创建的作业“onComplete”事件并让请求悬空，直到触发回调并且数据可以通过管道发送给用户。

  • 我看到的优点：“onSuccess”，所有数据都在用户
  • 我看到的缺点：根据作业的权重和活动作业数，用户请求可能会超时

在写这个问题时，事情对我来说越来越清楚了（场景 1，但发送了智能成功和更新事件）。无论如何，我想听听您使用的其他场景或对我的场景的进一步利弊！？

谢谢你的协助！

一些不必要的信息；对于 websockets，我使用的是 socket.io，用于创建 kue 和用于 pub/sub redis

4

2 回答 2

1

我刚刚写了这样的东西，我将这两种方法用于不同的事情。场景 1 最适合 IMO，因为它最符合现实，然后可以最准确地传达给用户。通过首先回复 200“是的，我收到了请求并按照您的请求创建了‘工作’”，然后您可以准确地更新 UI 以反映正在处理该请求。然后，您可以根据需要使用推送通道通知用户更新，例如进度百分比、错误和成功，但没有 UI“挂起”（显然您不会在场景 2 中挂起 UI，但这是一个尴尬的情况正在发生，用户界面只需要“猜测”工作正在处理中）。

于 2012-11-20T19:51:54.727 回答
0

场景 1 - 但不是响应200 OK，而是响应202 Accepted。来自维基百科： https ://en.wikipedia.org/wiki/List_of_HTTP_status_codes

202 Accepted 请求已被接受处理，但处理尚未完成。该请求最终可能会或可能不会被执行，因为在实际进行处理时它可能会被禁止。

这为工人错误的可能性敞开了大门。你只是说你接受了这个请求，并试图用它做点什么。

于 2016-02-29T18:13:12.310 回答