GitHub
VI. Процессы
Запускайте приложение как один или несколько процессов, не сохраняющих внутреннее состояние (stateless)
Приложение выполняется в среде выполнения как один или несколько процессов.
В простейшем случае код является независимым скриптом, среда выполнения – ноутбуком разработчика с установленной средой исполнения языка, а процесс запускается из командной строки (например, как python my_script.py). Другой крайний вариант – это рабочее развёртывание сложного приложения, которое может использовать много типов процессов, каждый из которых запущен в необходимом количестве экземпляров.
Процессы приложения двенадцати факторов не сохраняют внутреннее состояние (stateless) и не имеют разделяемых данных (share-nothing). Любые данные, которые требуется сохранить, должны быть сохранены в хранящей состояние сторонней службе, обычно, в базе данных.
Память и файловая система процесса может быть использована в качестве временного кэша для одной транзакции. Например, загрузка, обработка и сохранение большого файла в базе данных. Приложение двенадцати факторов не предполагает, что что-либо закэшированное в памяти или на диске будет доступно следующим запросам или задачам – с большим количеством разноплановых процессов высока вероятность, что следующий запрос будет обработан другим процессом. Даже с одним запущенным процессом перезапуск (вызванный развёртыванием, изменением конфигураций или переносом процесса на другое физическое устройство) приведёт к уничтожению всех локальных (памяти, файловой системы) состояний.
Упаковщики ресурсов (asset) (например, Jammit или django-compressor) используют файловую систему как кэш для скомпилированных ресурсов. Приложение двенадцати факторов предпочитает делать данную компиляцию во время этапа сборки, например, как в Rails asset pipeline, а не во время выполнения.
Некоторые веб-системы полагаются на “липкие сессии” – то есть кэшируют данные пользовательских сессии в памяти процесса приложения и ожидают того, что последующие запросы того же пользователя будут перенаправлены к тому же процессу. Липкие сессии являются нарушением двенадцати факторов и их никогда не следует использовать или полагаться на них. Данные пользовательской сессии являются хорошими кандидатами для хранилища данных, которое предоставляет функцию ограничения времени хранения, например, Memcached и Redis.