LINUX.ORG.RU

shared object

 , , ,


0

1

Ситуация такая, что settings не мутабельный. Писать в него не получается. Использовать redis или memcache - не получается. uid у инстансов динамический, поэтому использование uid_some_key проблематично, т.к при следующем старте инстанса uid будет уже другой. Надо как-то потом вычищать старые ключи и тд. Хотелось бы заюзать какой-то shared object, в который можно было бы писать полноценные list, dict, int/float, чтобы в этот shared object можно было читать/писать в течении всей жизни инстанса, после того, как инстанс перезапускается - эти данные очищались. Есть еще вариант писать в sqlite/pickle, но не хочется дергать постоянно диск. Что можно применить под эти нужды?

★★★

Ответ на: комментарий от eternal_sorrow

Использовать redis или memcache - не получается. uid у инстансов динамический, поэтому использование uid_some_key проблематично, т.к при следующем старте инстанса uid будет уже другой. Надо как-то потом вычищать старые ключи и тд

serg002 ★★★
() автор топика
Ответ на: комментарий от serg002

uid у инстансов динамический, поэтому использование uid_some_key проблематично, т.к при следующем старте инстанса uid будет уже другой

Что? Какой uid? Какие инстансы?

eternal_sorrow ★★★★★
()
Последнее исправление: eternal_sorrow (всего исправлений: 1)
Ответ на: комментарий от cobold

между процессами инстанса. Дело в том, что LocMem работает только в контексте одного процесса, если я запускаю что-то в celery task’e, то LocMem в другой celery task’e будет другой, т.е LocMem не shared между процессами

Да, типа глобального словаря, который будет shared в контексте конкретного инстанса и который будет храниться в памяти, чтобы при перезапуске он очищался

serg002 ★★★
() автор топика
Последнее исправление: serg002 (всего исправлений: 2)
Ответ на: комментарий от eternal_sorrow

uid генерируется инстансом при старте. Инстанс django

serg002 ★★★
() автор топика
Ответ на: комментарий от serg002

multiprocessing.shared_memory? А для чего вам нужно шарить переменные между процессами?

А инстансы джанги на одном хосте или на разных?

cobold ★★★★★
()
Последнее исправление: cobold (всего исправлений: 1)
Ответ на: комментарий от cobold

нужно выполнить синхронизацию кое-какую между инстансами

могут быть на одном, могут быть на разных

serg002 ★★★
() автор топика
Ответ на: комментарий от serg002

Синхронизацию какого рода? Если инстансы на разных хостах, то shared_memory не вариант. Насчёт redis. Рассматривался ли вариант с установкой TTL у данных? Т.е. при записи данных указываем опцию EX, при чтении дергаем EXPIRE тем самым продлевая время жизни. В таком случае ключи, к которым давно не было обращений удалит сам redis

cobold ★★★★★
()

Так не делай uid динамический, откажись от такой архитектуры в пользу стабилизации, а не динамики

menangen ★★★★★
()

Ты хочешь чего-то странного, лучше попробуй описать проблему, которую решаешь.

Получается, у тебя есть разные инстансы бекенда и воркеры сельдерея. Ты хочешь при их рестарте очистить какой-то общий кэш. Не понятно, что такое их рестарт, потому что у тебя может отвалиться одна нода, а потом вернуться обратно - нужно ли тогда все чистить? Кто должен быть тем сигналом для очистки?

В такой формулировке самое близкое что приходит в голову - использовать в качестве идентификатора не pid, а версию приложения, например хэш коммита. Тогда при запуске новой версии старые ключи в том же редисе или мемкеше перестанут читаться. Надо только не забыть экспайр. И, возможно, тебе захочется какую-то очистку при ручном рестарте без смены версии, можно например в бекенде навелосипедить обработку сигналов, понимая, что тут может быть гонка между инстансами, но не очень на нее надеяться и быть готовым к тому что это не отработает. Либо зайти с другой стороны, и очищать все ключи текущей версии при старте бекенда или воркера, но и тут может быть гонка и проблемы.

grazor ★★
()
Последнее исправление: grazor (всего исправлений: 2)

Хотелось бы заюзать какой-то shared object, в который можно было бы писать полноценные list, dict, int/float, чтобы в этот shared object можно было читать/писать в течении всей жизни инстанса, после того, как инстанс перезапускается - эти данные очищались

Прям идеально под мою либу. Я подозревал, что немало людей испытывает подобные проблемы в питоне.

Я сейчас все никак не придумаю, как подменить dict в объекте, чтобы можно было шарить классы, а не просто списки-массивы. В стандартной либе object захардкожен под встроенный dict, и потому простая замена __dict__ не прокатывает. По идее, единственный вариант — это либо заставлять пользователя все разделяемые объекты наследовать от одного класса, либо пересоздавать попадающие в разделяемую память объекты с модифицированным классом, у которого, опять же, базовый класс не object, а мой собственный класс в разделяемой памяти. Создатель POSH тоже уперся в подобную проблему и сделал примитивный перехват доступа к атрибутам:

http://poshmodule.sourceforge.net/posh/html/node6.html

К слову, в POSH есть реализация разделяемых списков и ассоциативных массивов — можешь попробовать ими воспользоваться, если тебе достаточно базовой функциональности.

Есть еще вариант писать в sqlite/pickle, но не хочется дергать постоянно диск

Если тебе достаточно пикла, то можно держать базу скулайта в оперативной памяти.

byko3y ★★★★
()
Ответ на: комментарий от serg002

posh

Так ак где сама либа-то?

http://poshmodule.sourceforge.net/posh-1.1.tar.gz

Моя не релизнута еще, вот-вот на днях планирую доделать минимальную поддержку классов и релизнуть. А то posh в 2003 году последний раз обновлялась, старовата она мальца.

byko3y ★★★★
()
Ответ на: комментарий от serg002

классы-то зачем? Достаточно стандартных типов данных

Тебе — да, достаточно. А если кто-то пожелает, например, засунуть defaultdict в разделяемые данные?

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.