ruby-on-rails - 在后端 Rails 应用程序中使用 Puma 和 Sidekiq

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

另一个问题是您的服务器处理 Web 请求所需的时间长度。

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

与外部 API 的交互有时会很慢，在最坏的情况下，由于远程服务器没有响应，或者网络中断或变慢，它可能非常不可靠。 Sidekiq 是将您的应用程序(和您的最终用户)与远程 API 响应缓慢的可能性隔离的好方法。想象一下，由于某种原因远程 API 运行缓慢，并且它的平均响应时间已减慢到每个请求 2 秒。在这种情况下，您只能使用 5 个 worker 处理 2.5 个请求/秒。有了更多的流量，您的最终用户可能会在您的应用程序上的任何页面响应之前等待很长时间，即使是那些不进行远程 API 调用的页面，因为您的所有网络 worker 可能都在等待缓慢的远程 API回复。随着流量不断增加，您的用户将开始出现连接超时。

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

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