Является ли Rails shared-nothing или может отделить запросы от доступа к тем же переменным среды выполнения?

Ответ 1

Короче:

• Нет, Rails никогда не запускается в среде с общим доступом.
• Будьте параноидальными относительно переменных класса и переменных экземпляра класса.

Более длинная версия:

Процессы Rails начинают свой жизненный цикл, загружая фреймворк и приложение. Они, как правило, запускают только один поток, который будет обрабатывать множество запросов в течение его жизни. Поэтому запросы будут отправляться строго последовательно.

Тем не менее, все классы сохраняются в разных запросах. Это означает, что любой объект, на который ссылаются ваши классы и метаклассы (такие как переменные класса и переменные экземпляра класса), будет разделяться между запросами. Это может укусить вас, например, если вы попытаетесь memoize методы (@var ||= expensive_calculation) в своих методах класса, ожидая, что он будет сохраняться только во время текущего запроса. В действительности расчет будет выполняться только по первому запросу.

На первый взгляд может показаться приятным реализовать кэширование или другое поведение, зависящее от персистентности запросов. Как правило, это не так. Это связано с тем, что большинство стратегий развертывания будут использовать несколько процессов Rails для противодействия их собственной однопоточной природе. Просто не здорово блокировать все запросы, ожидая медленного запроса к базе данных, поэтому простой выход - это вызвать больше процессов. Естественно, эти процессы ничего не разделяют (за исключением некоторой памяти, которую вы не заметите). Это может укусить вас, если вы сохраняете данные в переменных класса или переменных экземпляра класса во время запросов. Затем, как-то, иногда кажется, что материал присутствует, а иногда кажется, что его нет. (На самом деле, конечно, данные могут или не могут присутствовать в каком-то процессе и отсутствуют в других).

Некоторые конфигурации развертывания (особенно JRuby + Glassfish) фактически многопоточны. Rails является потокобезопасным, поэтому он может справиться с этим. Но ваше приложение не может быть потокобезопасным. Все экземпляры контроллера выбрасываются после каждого запроса, но, как известно, классы разделяются. Это может укусить вас, если вы передаете информацию в переменных класса или в переменных экземпляра класса. Если вы неправильно используете методы синхронизации, вы вполне можете оказаться в азартном состоянии гонки.

В качестве побочного примечания: Rails обычно запускается в однопоточных процессах, потому что реализация Ruby thread всасывает задницу. К счастью, в Ruby 1.9 ситуация немного лучше. И намного лучше в JRuby.

При одновременном использовании обеих этих реализаций Ruby кажется вероятным, что многопотоковые стратегии развертывания Rails также получат популярность и количество. Это хорошая идея написать ваше приложение с многопоточным диспетчером запросов уже.

Ответ 2

Вот относительно простой пример, который иллюстрирует, что может произойти, если вы не будете осторожны при изменении общих объектов.

• Создайте новый проект Rails: rails test

• Создайте новый файл lib/misc.rb и вставьте в него следующее:

  class Misc
    @xxx = 'Hello'
    def Misc.contents()
      return @xxx
    end
  end
  

• Создайте новый контроллер: ruby script/generate controller Posts index

• Измените app/views/posts/index.html.erb, чтобы содержать этот код:

  <%
    require 'misc'; y = Misc.contents() ; y << ' (goodbye) '
  %>
  <pre><%= y %></pre>
  

  (Здесь мы модифицируем неявно разделяемый объект.)

• Добавьте маршруты RESTful в config/routes.rb.
• Запустите сервер ruby script/server и несколько раз загрузите страницу /posts. Вы увидите количество строк ( goodbye), увеличивающихся на единицу при каждой последующей перезагрузке страницы.

Ответ 3

В вашем среднем развертывании с использованием Passenger у вас, вероятно, есть несколько процессов приложений, которые не имеют ничего общего между ними, кроме классов внутри каждого процесса, которые поддерживают свое (статическое) состояние из запроса для запроса. Однако каждый запрос создает новый экземпляр ваших контроллеров.

Вы можете назвать это кластером различных сред общего состояния.

Чтобы использовать свою аналогию Java, вы можете выполнить кэширование и заставить его работать с запросом на запрос, вы просто не можете предположить, что он будет доступен по каждому запросу.

Ответ 4

Общие - ничто иногда не является хорошей идеей. Но не тогда, когда вам приходится загружать большую инфраструктуру приложения и большую модель домена и большую конфигурацию по каждому запросу.

Для повышения эффективности Rails сохраняет некоторые данные в памяти для совместного использования между всеми запросами на всю жизнь приложения. Большинство этих данных доступны только для чтения, поэтому вам не следует беспокоиться.

Когда вы пишете свое приложение, держитесь подальше от записи на общие объекты (исключая, например, базу данных, которая поставляется с готовым элементом управления concurrency), и все должно быть хорошо.