4

我有一个后端 Rails 服务器Sidekiq，它用作 API 服务器。该应用程序的工作原理如下：

  1. 我的 Rails 服务器同时接收来自传入 API 客户端的许多请求。

  2. 对于这些请求中的每一个，Rails 服务器都会将作业分配给 Sidekiq 服务器。Sidekiq 服务器向外部 API（如 Facebook）发出请求以获取数据，并对其进行分析并将结果返回给 Rails 服务器。

例如，如果我从我的 API 客户端收到 10 个传入请求，对于每个请求，我需要向外部 API 服务器发出 10 个请求，获取数据并进行处理。

我的挑战是让我的应用程序同时响应传入的请求。也就是说，对于每个传入的请求，我的应用程序应该并行处理：调用外部 API、获取数据并返回结果。

现在，我知道 Puma 可以为 Rails 应用程序添加并发性，而 Sidekiq 是多线程的。

我的问题是：如果我已经拥有 Puma，我真的需要 Sidekiq 吗？同时使用 Puma 和 Sidekiq 有什么好处？

特别是，使用 Puma，我只需从我的 Rails 应用程序调用我的外部 API 调用、数据处理等，它们将自动并发。

4

2 回答 2

6

是的，您可能确实想使用 Puma 和 Sidekiq。这里真的有两个问题在起作用。

并发（您似乎已经知道）是可以同时处理的 Web 请求的数量。使用像 Puma 或 Unicorn 这样的应用服务器肯定会帮助您获得比默认的 web 砖服务器更好的并发性。

另一个问题是服务器处理 Web 请求所花费的时间。

这两件事相关的原因是您的应用程序可以处理的每秒请求数是每个请求的平均处理时间和接受请求的工作进程数的函数。假设您的平均响应时间为 100 毫秒。然后一个 web worker 每秒可以处理 10 个请求。如果您有 5 个工作人员，那么您每秒可以处理 50 个请求。如果您的平均响应时间是 500 毫秒，那么您可以使用单个工作人员处理 2 个请求/秒，使用 5 个工作人员处理 10 个请求/秒。

与外部 API 的交互有时会很慢，在最坏的情况下，远程端无响应的服务器或网络中断或速度下降可能会非常不可靠。Sidekiq 是将您的应用程序（和您的最终用户）与远程 API 响应缓慢的可能性隔离开来的好方法。想象一下，远程 API 由于某种原因运行缓慢，并且来自它的平均响应时间已减慢到每个请求 2 秒。在这种情况下，您只能处理 5 个工作人员的 2.5 个请求/秒。如果流量超过了您的最终用户可能会开始等待很长时间才能响应您的应用程序上的任何页面，即使是那些不进行远程 API 调用的页面，因为您的所有网络工作者可能都在等待缓慢的远程 API回复。

使用 Sidekiq 的想法是将等待外部 API 的时间与 Web Worker 分开。您基本上会从您的用户那里获取数据请求，将其传递给 Sidekiq，然后立即向用户返回一个基本上说“我们正在处理您的请求”的响应。Sidekiq 然后可以接手工作并提出外部请求。获得数据后，它可以将该数据保存回您的应用程序。然后，您可以使用 Web 套接字向用户推送数据准备就绪的通知。或者甚至将数据直接推送给他们并相应地更新页面。（您也可以使用轮询让页面不断询问“它准备好了吗？”，但这很快就会变得非常低效。）

我希望这是有道理的。如果您有任何问题，请告诉我。

于 2013-09-29T06:25:52.757 回答
4

Sidekiq 与 Resque 和 Delayed Job 一样，旨在提供来自队列的异步作业处理。

如果您不需要将作业排队并异步运行，那么使用 Sidekiq 并没有实质性的好处（或危害）。

如果任务需要同步运行（听起来您可能会这样做——不清楚客户端是在等待数据还是只是请求作业运行），Sidekiq 及其相关工具可能是该作业的错误工具。使用 Sidekiq 或其他解决方案时无法保证处理时间；作业被推到堆栈的末尾，无论它可能有多长，并且在轮到它们之前不会被处理。如果客户端正在等待数据，它们可能会在您的工作池处理他们的工作之前很久就超时。

于 2013-09-29T06:21:44.247 回答