从Rails 7.1开始，Puma将自动生成x个工作线程，其中x是可用处理器的数量。
这就带来了一个问题：如何在一个简单的码头化Rails生产应用中处理工人。
如果一个简单的Rails应用程序偶尔会异步发送一些邮件，并定期清理一些ActiveRecord Blob，那么还需要像Sidekiq这样的worker Gem吗？或者Puma的默认配置足以完成这项工作吗？
从Rails 7.1开始，Puma将自动生成x个工作线程，其中x是可用处理器的数量。
这就带来了一个问题：如何在一个简单的码头化Rails生产应用中处理工人。
如果一个简单的Rails应用程序偶尔会异步发送一些邮件，并定期清理一些ActiveRecord Blob，那么还需要像Sidekiq这样的worker Gem吗？或者Puma的默认配置足以完成这项工作吗？
1条答案
按热度按时间bxpogfeg1#
如果你的应用程序非常简单，并且你不需要任何类型的队列持久性和/或崩溃安全机制，你可以依靠Rail的ActiveJob，并将其设置为使用主进程的RAM，而不是任何第三方队列系统，如Sidekiq。
请注意，Sidekiq不仅仅是多线程的应用程序。它可以利用Redis/Memcached来给予你的worker例程一些一致性和持久性，例如，如果你的主应用程序崩溃，你只使用ActiveJob，而队列保存在内存中，你将丢失所有等待执行的作业。如果你使用的是Sidekiq，而你的主应用程序崩溃了，你的作业定义仍然是坚持下去，你什么也不会失去。
所以答案是肯定的，你可以只使用Rails内置的ActiveJob而不使用Sidekiq或类似的工具来执行Java作业，但根据你的用例，不推荐这样做。