ruby-on-rails - Rails 最佳实践 : background process/thread?

Question

我来自 PHP 环境(至少在 Web 开发方面)并进入了美丽的 Ruby 世界，所以我可能有一些愚蠢的问题。我想在不使用 PHP 时会有一些根本不同的选项可用。

在 PHP 中，我们使用内存缓存来存储我们想要在页面顶部的栏中显示的警报。当发生生成警报的事情时(例如发布新的博客文章)，每 5 分钟左右运行一次的 cron 脚本会将这些信息放入内存缓存中。

现在，当用户访问该站点时，我们会在内存缓存中查找他们尚未消除的任何警报，然后我们会显示它们。

我猜我可以在 Rails 中做一些不同的事情，就是绕过对 cron 脚本的需要，以及在每个请求中查看内存缓存的需要，方法是使用单例和在单独的线程从内存缓存复制到这个单例。从理论上讲，这比每个请求检查一次内存缓存更优化，并且还将轮询逻辑封装到一个地方，而不是在 cron 任务和查找逻辑之间拆分。

我的问题是:在 Rails 应用程序运行时在后台运行某种运行循环是否有任何注意事项？我从 Objective-C/Java 了解多线程的含义，但我具体询问的是 Rails (3) 环境。

基本上是这样的:

class SiteAlertsMap < Hash
  include Singleton

  def initialize
    super
    begin_polling
  end

  # ... SNIP, any specific methods etc ...

  private

    def begin_polling
      # Create some other Thread here, which polls at set intervals
    end
end

这让我想到了一个类似的问题。我们将(加密的)任务推送到 SQS 队列，用于与电子商务相关的事情和长时间运行的后台任务。我们不为此使用 cron，而是有一个用 PHP 编写的工作守护进程，它在后台运行。现在当我们部署时，我们必须关闭这个 worker 并从新的代码库重新启动它。在 Rails 中，我可以通过 Rails 服务器( unicorn )本身以某种方式启动和停止此过程吗？我不认为我会在单独的线程中在主进程上运行它，因为我们经常希望将它作为一个进程来单独控制，但如果它能在 Web 应用程序运行时方便地运行，那就太好了。

Answer 1

在 ruby​​ 中为后台进程线程化将是一个可怕的错误，尤其是当您使用多进程服务器时。将 unicorn 与 4 个工作进程一起使用意味着您将从每个工作进程进行轮询，这不是您想要的。 Ruby 并没有真正的线程，它在 1.8 中有绿色线程，在 1.9 IIRC 中有一个全局解释器锁。许多 gem 和库也是令人讨厌的非线程安全的。

使用内存缓存仍然是您的最佳选择，如果您正确设置它，您应该只会看到它会增加一两毫秒的请求时间。另一种可以让您在保持这些警报的同时产生最少额外开销的好处的选择是将这些警报存储在 redis 中。这将更好地保护您免受内存缓存崩溃或服务器重启等问题的影响。

对于后台作业，您应该使用与现在类似的方法，但是有几个现成的处理程序，例如 resque , delayed_job , 和其他一些。如果您绝对必须使用 SQS 作为后端队列，您可能会找到一些代码来帮助您，否则您可以自己编写。这仍然需要在代码更改时重新启动另一个守护进程。在实践中，这并不是一个大问题，因为最佳实践要求使用像 capistrano 这样的部署系统，在该系统中可以轻松添加规则以在部署时反弹守护进程。我使用 monit 监视守护进程，因此重启它就像告诉 monit 重启它一样简单。

一般来说，Ruby 在线程方面不像 Java/Objective-C。它遵循更类似于 Unix 的基于进程的隔离模型，但社区已经提出了最佳实践和方法来使这比其他语言更不痛苦。 Ruby 确实需要更多地注意设置它的堆栈，因为它不像启用 mod_php 和复制一些文件那么简单，但是一旦理解了选择和体系结构，就更容易推理如何您的应用程序有效。在我看来，进程模型对于 Web 应用程序来说要好得多，因为它将代码和状态与其他正在运行的操作的影响隔离开来。隔离还使应用程序更易于在分布式系统中使用。