ruby-on-rails - TimeCop 在生产中基于每个请求

Question

我有一个使用 MRI ruby​​ 和 Unicorn 作为应用服务器的 Rails 应用。该应用程序提供了一个为期 10 周的健身计划，我为以管理员身份登录的用户构建了一个功能，以便能够“时间旅行”到计划中的不同周。基本上，它只是设置一个 session 变量，其中包含他们“时间旅行”到的日期，并且每个请求，它在开始时时间旅行到那个点，然后在结束时返回。代码如下。

我限制了非生产环境的功能，因为担心一个人的时间旅行可能会影响其他用户(因为 TimeCop 猴子补丁核心类)。但是，考虑到 MRI 并不是真正的多线程，我现在认为这是一种不合理的恐惧，并且在生产中使用“时间旅行”功能应该没有危险。

在处理单个请求的持续时间内(如果用户使用“时间旅行”，则核心类被 TimeCop 猴子修补的时间)，应该不可能有任何其他请求运行在同一个 ruby 进程上。

这是正确的吗？或者其他用户的请求是否会以我不知道的方式受到 TimeCop 对核心类的更改的影响？

我使用的代码如下:

module TimeTravelFilters
  extend ActiveSupport::Concern

  included do
    if Rails.env.development? || Rails.env.staging?
      around_action :time_travel_for_request
    end
  end

  def time_travel_for_request
    time_travel
    yield
    time_travel_return
  end

  def time_travel
    if session[:timetravel_to_date]
      Timecop.travel(session[:timetravel_to_date])
    end
  end

  def time_travel_return
    Timecop.return
  end
end

Answer 1

MRI 的全局解释器锁确实意味着 2 个线程不会并发执行，但其粒度远小于处理一个请求。

碰巧 unicorn 不使用线程进行并发，所以你会没事的，但是当你切换到另一个服务器(例如 puma)的那一天，你就会大吃一惊。

这也会影响日志中的数据、任何更新的 created_at/updated_at 时间戳等。如果您使用这些服务，它也可能会影响由 newrelic、airbrake 等服务收集的监控数据。另一个看似完全无关的例子是对 AWS 的 api 请求:验证这些请求的签名包括一个时间戳，如果您不同步超过几分钟，它们就会失败。假设 Time.now 是准确的，有太多代码(其中大部分是您无法控制的)。

您最好识别那些隐式使用当前时间的代码位并更改它们以允许将所需时间作为参数传递。

顺便说一句，如果 Controller 引发异常，我认为您的代码会将更改后的时间留在原地