我有一个带Sidekiq的后端Rails服务器，它作为API服务器。该应用程序的工作原理如下：
My Rails服务器同时收到来自传入API客户端的许多请求。
对于这些请求中的每一个，Rails服务器都会将作业分配给Sidekiq服务器。 Sidekiq服务器向外部API（例如Facebook）发出请求以获取数据，并对其进行分析并将结果返回给Rails服务器。
例如，如果我从API客户端收到10个传入请求，则对于每个请求，我需要向外部API服务器发出10个请求，获取数据并对其进行处理。
我的挑战是让我的应用程序同时响应传入的请求。也就是说，对于每个传入的请求，我的应用程序应该并行处理：调用外部API，获取数据并返回结果。
现在，我知道Puma可以为Rails应用添加并发性，而Sidekiq是多线程的。
我的问题是：如果我已经拥有Puma，我真的需要Sidekiq吗？使用Puma和Sidekiq会有什么好处？
特别是，对于Puma，我只是从我的Rails应用程序调用我的外部API调用，数据处理等，它们将自动并发。
答案 0 :(得分：6)
是的，你可能想要使用Puma和Sidekiq。这里真的有两个问题。
并发（您似乎已经知道）是可以同时处理的Web请求数。使用像Puma或Unicorn这样的应用服务器肯定会帮助您获得比默认Web砖服务器更好的并发性。
另一个问题是服务器处理Web请求所需的时间长度。
这两件事情相关的原因是您的应用可以处理的每秒数量或请求数量是每个请求的平均处理时间和接受请求的工作进程数量的函数。假设你的平均响应时间是100毫秒。然后，单个Web工作者可以每秒处理10个请求。如果你有5个工人，那么你每秒可以处理50个请求。如果你的平均响应时间是500毫秒，那么你可以用一名工人处理2雷亚尔/秒，每5工人处理10雷亚尔/秒。
有时与外部API进行交互可能会很慢，而在最糟糕的情况下，远程端无响应的服务器或网络中断或速度减慢可能非常不可靠。 Sidekiq是一种很好的方法，可以使您的应用程序（和您的最终用户）与远程API响应缓慢的可能性隔离开来。想象一下，由于某种原因，远程API运行缓慢，并且每个请求的平均响应时间减慢到2秒。在这种情况下，您只能处理5名工人的2.5雷亚尔/秒。如果流量超过最终用户可能会在应用上的任何页面响应之前开始等待很长时间，即使是那些没有进行远程API调用的人，因为所有的Web工作者可能都在等待缓慢的远程API回复。随着流量持续增加，您的用户将开始获得连接超时。
使用Sidekiq的想法是，您将等待外部API的时间与Web工作者分开。您基本上是从用户那里获取数据请求，将其传递给Sidekiq，然后立即向用户返回一个基本上说“我们正在处理您的请求”的响应。然后Sidekiq可以接收工作并提出外部请求。拥有数据后，它可以将数据保存回您的应用程序。然后，您可以使用Web套接字向用户发送数据已准备好的通知。甚至可以直接将数据推送给他们并相应地更新页面。 （您也可以使用轮询让页面不断询问“它已准备就绪吗？”，但这种效率非常低效。）
我希望这是有道理的。如果您有任何问题，请告诉我。
答案 1 :(得分：4)
Sidekiq，与Resque和Delayed Job一样，旨在从队列中提供异步作业处理。
如果您不需要将作业排队并异步运行，则使用Sidekiq没有实质性的好处（或伤害）。
如果任务需要同步运行（听起来你可能 - 目前尚不清楚客户端是在等待数据还是只是请求运行这些工作），Sidekiq及其亲属可能是错误的工具。使用Sidekiq或其他解决方案时，无法保证处理时间;作业被推到堆栈的末端，无论多长，都可以，并且在轮到它们之前不会被处理。如果客户端正在等待数据，则在工作池处理其作业之前，它们可能会超时 long 。