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