LINUX.ORG.RU

Архитектура демона на питоне и общение с ним

 , ,


3

3

Вот прямо щас пишу демона для Asterisk на питоне, смотрю в этот гайд http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/

Суть работы: Когда демону приходит задание (json-объект) он либо откладывает его, либо начинает выполнять сразу (создание некоторого количества файлов в /tmp, перемещение их в определенную папку и её мониторинг на предмет их изменения/исчезновения). На протяжении всей работы он должен знать какие задания у него сейчас есть, какие он выполнил и что делает сейчас. После экстренного выключения / остановки он должен не терять эти самые задания. В любой момент работы он может получить запрос состояния, на который он должен вернуть json-документ со списком заданий и ходом выполнения.

Демона пишу первый раз, пока не уверен что выбрал правильный путь. Чтобы хранить задания, нужно внешнее хранилище. Я хочу использовать mongodb.

Как правильно организовать хранение списка выполняющихся задач?

Можно вообще всё общение сделать через mongo - новое задание сразу класть в mongo (вообще не использовать внутренние переменные) и начинать его выполнение. После выполнения каждого шага, делать запись в mongo. На любой запрос - брать данные из mongo. Таким образом, при аварийном завершении, я легко восстановлю состояние работы и списки задач.

Если же на каждое задание создавать экземпляр класса, хранить список этих экземпляров, то при завершении работы все данные будут утеряны.

Я правильно понимаю?

и второй вопрос: как общаться с python демоном посредством json? Просто получать его как строку через argv и дальше преобразовывать в объект?

p.s. демон будет вызываться только вебсервером, поэтому интересует системное, а не сетевое взаимодействие


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

Лучше, наверное, сделать тупую софтину (демон), который только получает данные и запихивает в базу. А отдельно будет крутиться либо демон, либо просто программа, которая обнаруживает новые задания и что-то с ними делает. Обнаружение можно сделать либо через системные сигналы, либо через средства базы, смотря какая скорость обработки требуется.

Iron_Bug ★★★★★ ()

Обрати внимание вот на этот фреймворк, он может сэкономить тебе не мало сил, поскольку изначально заточен под MongoDB и Rest и работает с ними «ис каропки». Первая даст тебе атомарные операции, нужные для реализации очередей, и скорость, а поддержка Rest даст тебе работу с json

Удачи.

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

Спасибо, но у тебя там веб, для него можно post/get. А у меня скрипт работает в пределах локалхоста, юзать http немного костылевато =)

JANB ()
Ответ на: комментарий от JANB

Судить конечно тебе, но имей ввиду, что ты все равно упрешься в протокол обмена. Я имею ввиду транспортный уровень. Лично я считаю, что чем городить огород с велосипедами, лучше использовать уже имеющийся транспорт (протокол http 1.1), работающий одинаково хорошо как в пределах локалхоста, так и за его пределами. Протокол, который понимают и пропускают сквозь себя большинство маршрутизаторов.

А систему команд демона можно легко уложить в «Прочитать» (GET), «Добавить» (POST), «Модифицировать» (PUT) и «Удалить» (DELETE)

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

Я голосую за второй вариант. Просто, надежно, никаких проблем в реализации.

За этот?

на каждое задание создавать экземпляр класса

Тогда как восстанавливать данные о задачах при завершении работы?

JANB ()
Ответ на: комментарий от JANB

За этот?

Это уже третий. Я про хранение всего в монге.

umren ★★★★★ ()

А почему бы не решить задачу по проще: написать модуль к * pbx_originatecallifkickedbymywebserver который собственно будет заниматься тем что задумано Вами(если телепатически интерфейс не глючит)? И не нужно будет заниматься идиотизмом типа слежения за ходом дозвона по наличию/содержимому .call файлов, и можно будет непосредственно из ядра * получать интересующие события. Связь с веб-сервером сможете держать любым методом доступно ОС, хотя тут будет вполне достаточно принимать команды через AMI, на худой конец CLI. Хранить состояние Ваших задач можно будет как и во внешней базе нужной вам архитектуры, так и во внутренней базе SQLite/BDB. Даже если * лежит, остается доступ к хранилищу состояний, который не требует работающего демона по большому то счету.

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

Вы бог!

Я не занимаюсь чисто астериском, я просто программист. Мне сказали генерить .call файлы определенного формата и делать move в папку астериска. Я вообще не был в курсе что есть другие способы общения с этой замечательной штукой.

Вот сейчас, например, читаю про AMI и AJAM, и проигрываю в голове сценарии как убить нашего админа.

Вопрос один: посоветуйте вменяемую книжку по астериску? Разумеется, мне нужно именно взаимодействие с ним, а не его хитрая настройка. Язык не важен.

JANB ()
Ответ на: комментарий от Iron_Bug

По-моему, у монги надёжности от родясь не было. Это легко гуглится. Они там что-то не так давно ковыряли на эту тему, но вот у меня нет к этому доверия.

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

не знаю. первый раз ваще слышу. гуголь сказал, что это какой-то форум. я хз.

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

Только если это не жалко потом внезапно потерять.

никто ничего не гарантирует. поломать можно что угодно. если очень боитесь потерять - берите Oracle + EMC хранилище. полная гарантия: даже если аппарат сдохнет, за 4 часа его восстановят. у нас (опсос и провайдер) стоят такие в серверной. ничего не теряется. только стоит эта фигня пару мильёнов баксов. зато оооочень надёжно :)

а так, без паранойи и дёшево: кластеры, дублирование, зеркала... никто не отменял обычных админских средств защиты данных.

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

никто ничего не гарантирует

А что из монги уже выпилили блокировки на чтение?
А что из монги уже выпилили ад и израиль при удалении данных без компактизации?
А что монга уже научилась адекватно реагировать на аварийные отключения?

По своему опыту могу сказать, что хранить в монге что-то большее, чем логи, которые не страшно профукать, не стоит.

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

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

Если я правильно Вас понял, то mongodb весьма ненадежна. А redis для моей задачи лучше подходит? Или что использовать?

Просто мне кажется, что надежности mongodb для моей задачи хватит за глаза. Она же пишет журнал. Ну, «моргнул» свет, перезагрузился комп, я запускаю mongod --repair, все данные восстановились, продолжаем работу. Или я неправ?

JANB ()
Ответ на: комментарий от JANB

А redis для моей задачи лучше подходит?

Redis тоже подходит + он быстрее, но надежность мне кажется еще ниже :) а надежности Mongo хватит за глаза, местные пациенты рассматривают какие-то нереальные случаи или опирается на опыт альфа версии Mongo.

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

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

К скорости требования смешные - в секунду не больше 30 операций записи и не больше 100 чтений. Но это потолок, обычно будет 4 записи на 20 чтений. Writer/reader будет один - вебсервер.

JANB ()
Ответ на: комментарий от JANB

ну тогда бери монгу и не забывай ее ручками бэкапить.

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

потому что дефолтная запись ничего не гарантирует.

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