Постоянный объект Python в памяти для сервера nginx/uwsgi

То, что вы предлагаете, напрямую невозможно. Поскольку новые процессы могут запускаться и останавливаться вне вашего контроля, нет никакого способа сохранить собственные данные Python в памяти.

Однако есть несколько способов обойти это.

Часто достаточно одного уровня хранилища ключей и значений. А иногда наличие буферов фиксированного размера для значений (которые вы можете использовать непосредственно как объекты str/bytes/bytearray; все остальное, что вам нужно struct там или иным образом сериализовать) — это все, что вам нужно. В этом случае встроенная система кэширования uWSGI позаботится обо всем. тебе нужно.

Если вам нужен более точный контроль, вы можете посмотреть, как кеш реализован поверх SharedArea и настройте что-нибудь. Однако я бы не рекомендовал этого. По сути, это дает вам тот же API, который вы получаете с файлом, и единственные реальные преимущества по сравнению с простым использованием файла заключаются в том, что сервер будет управлять временем жизни файла; он работает на всех языках, поддерживаемых uWSGI, даже на тех, которые не поддерживают файлы; и это упрощает миграцию вашего пользовательского кеша в распределенный (многокомпьютерный) кеш, если вам это понадобится позже. Я не думаю, что что-то из этого относится к вам.

Еще один способ получить плоское хранилище значений ключа, но без буферов фиксированного размера, — это Python stdlib anydbm. Поиск ключ-значение настолько питонический, насколько это вообще возможно: он выглядит точно так же, как dict, за исключением того, что его резервная копия хранится в находящейся на диске базе данных BDB (или аналогичной), кэшируется соответствующим образом в памяти, а не хранится во внутренней памяти. хеш-таблица памяти.

Если вам нужно обрабатывать несколько других простых типов — все, что невероятно быстро распаковывается/собирается, например ints, — вы можете рассмотреть shelve.

Если ваша структура достаточно жесткая, вы можете использовать базу данных ключ-значение для верхнего уровня, но получить доступ к значениям через ctypes.Structure или де/сериализовать с помощью struct. Но обычно, если вы можете это сделать, вы также можете удалить верхний уровень, после чего все ваше дело будет просто одним большим Structure или Array.

В этот момент вы можете просто использовать обычный файл для хранения — либо mmap (для ctypes), либо просто open и read (для struct).

Или используйте общие ctypes объекты multiprocessing для прямого доступа к Structure из общей области памяти.

Между тем, если вам на самом деле не нужны все данные кеша все время, а только фрагменты время от времени, то это именно то, для чего нужны базы данных. Опять же, anydbm и т. д. могут быть всем, что вам нужно, но если у вас сложная структура, нарисуйте ER-диаграмму, превратите ее в набор таблиц и используйте что-то вроде MySQL.

Вы ничего не сказали о записи этих данных обратно, они статичны? В этом случае решение очень простое, и я понятия не имею, что происходит со всеми ответами «это невозможно».

Рабочие процессы Uwsgi являются постоянно работающими приложениями. Таким образом, данные абсолютно сохраняются между запросами. Все, что вам нужно сделать, это сохранить данные в глобальной переменной, вот и все. И помните, что это для каждого рабочего, а рабочие время от времени перезапускаются, поэтому вам нужны правильные стратегии загрузки/аннулирования.

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

Я никогда не пробовал это сам, но не могли бы вы использовать SharedArea uWSGI? чтобы выполнить то, что вы после?

«Насколько мне известно, данные Python в памяти НЕ будут сохраняться во всех запросах, если только я не ошибаюсь».

вы ошибаетесь.

весь смысл использования uwsgi поверх, скажем, механизма CGI заключается в том, чтобы сохранять данные между потоками и экономить накладные расходы на инициализацию для каждого вызова. вы должны установить processes = 1 в файле .ini, иначе, в зависимости от настроек uwsgi, он может запускать более 1 рабочего процесса от вашего имени. зарегистрируйте env и найдите 'wsgi.multiprocess': False и 'wsgi.multithread': True, и все потоки uwsgi.core для одного рабочего должны показывать одни и те же данные.

вы также можете увидеть, сколько рабочих процессов и «основных» потоков под каждым у вас есть, используя встроенную функцию stats-server.

вот почему uwsgi предоставляет функции lock и unlock для управления хранилищами данных несколькими потоками.

вы можете легко проверить это, добавив маршрут /status в свое приложение, которое просто выводит JSON-представление вашего глобального объекта данных и просматривает его время от времени после действий, которые обновляют хранилище.