我正在尝试与 Google 的日历 API 进行交互。到目前为止，我的测试显示插入单个事件的响应时间为 5-10 秒，并且我可能需要一次导出数千个事件[不要问]。这似乎可能会在不合理的时间内从我的队列中大量发送垃圾邮件。 (此应用程序中 95% 的当前作业在 <300 毫秒内完成，因此这将使适当分配资源变得更加困难。)
我目前在此应用中使用 Faraday 来调用其他更快的 Google API。 Faraday wiki 建议使用 Typhoeus 进行并行 HTTP 请求；然而，将 Typhoeus 与 Sidekiq 一起使用被视为 "a bad idea"截至 2014 年。
Typhoeus 仍然是一个坏主意吗？如果是这样，在 Sidekiq 工作线程中生成 N 个线程，在每个线程中发出 HTTP 请求，然后等待所有线程重新加入是否合理？是否有其他方法可以完成这个极度依赖 I/O 的任务，而不需要投入更多的工作人员来解决这个问题？我应该要求我的经理增加我们的 Sidekiq Enterprise 支出吗？ ;) 或者我应该将这些作业放入低优先级队列中，并告诉具有荒谬习惯的用户他们只需要等待？
最佳答案
在 Sidekiq 作业线程中使用线程是合理的。构建自己的线程基础设施是不合理的。您可以将可重用的线程池与concurrent-ruby或parallel gem一起使用，您可以使用线程安全且允许并发请求的http客户端等。HTTP。 rb 是 Tony Arcieri 提供的一个很好的工具，但普通的旧 net/http 也可以工作:
https://github.com/httprb/http/wiki/Thread-Safety
请记住，存在一些复杂性:作业可能会重试，如何处理 HTTP 客户端引发的错误？如果您不将这些请求与作业一对一拆分，您可能需要跟踪每个请求，否则幂等性就会成为问题。
我们随时欢迎您增加 Sidekiq Enterprise 线程数。 :-D
关于ruby - 来自单个 Sidekiq 工作线程的并发 HTTP 请求？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50338326/