Каков предпочтительный способ написать мои демоны linux?

Question

Привет всем

У меня есть сайт PHP, который должен использовать некоторые кэшированные данные (например, хранящиеся в Memcache). Данные должны храниться в кеше, когда демоны извлекают его из веб-служб, а некоторые из них также должны храниться на сервере MySQL.

Демонов должны сделать следующее:

1. Fetch валютных курсов, анализировать их и хранить их в базе данных, а также в два разделенных memcaches в раздельных машинах.
2. Получить финансовые показатели и сохранить их в разделенных memcaches.
3. Извлечь большие XML-данные и сохранить их в двух разделенных memcache.

Я могу написать эти демоны в C/C++/Perl/PHP/Python.

Мне нужно решить, на каком языке/сценарии я должен выбрать для реализации этих демонов. Преимущество использования PHP для этого заключается в том, что я могу использовать API, используемый самим приложением веб-сайта. Еще одно преимущество заключается в том, что PHP легко, и все это знают, поэтому я не буду привязан к поддержке этих демонов, но, с другой стороны, PHP медленнее и потребляет гораздо больше ресурсов.

Основным недостатком использования другого языка, кроме PHP, является то, что сложнее поддерживать код, написанный на C/C++/Perl. В настоящее время, я полагаю, что это не так часто приходится выполнять с помощью C/C++/Perl. Разве я не прав, говоря это?

Что вы посоветуете мне в этом случае?

Answer 1

Perl и Python отвечают за ответы по умолчанию для написания таких скриптов. Но не важно (много), какой язык вы используете, если пишете хороший код. Чем важнее то, как вы справляетесь со своим скриптом при сбое.

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

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

И для этого я использовал monit. Отличный инструмент.

Answer 2

Лучший вариант, вероятно, будет PHP для простоты/повторного использования кода.

PEAR System Daemon
Create daemons in php

EDIT
Из того, что я могу сказать, что это просто передавая данные по всему, это не производительность беспокоиться. И об использовании ресурсов просто убедитесь, что не исчерпывается max_memory (с помощью потоковой передачи, возможно, или настройте много). Прерывание и лог-операции, которые занимают слишком много времени. Подключите к базе данных в цикле при сбое SQL-операции и т. Д.

ПРИМЕЧАНИЕ ОСТОРОЖНО
Программирование демона сложно, и многое может пойти не так. Учитывайте все точки отказа.

Также обратите внимание, что Perl намного более разбирается в отношении демонов, чем PHP. Я ушел из c/C++, так как производительность (данные для передачи данных) не является проблемой, а программирование демона достаточно сложно, так как это так, зачем добавлять беспокойства в утечки памяти, segfaults и т. Д.?

Answer 3

short: Я бы использовал Python.

больше: Я попытался PHP в режиме CLI, я испытал много утечки памяти, конечно, из-за плохие PHP LIBS или PHP библиотек, с которыми никогда не было, хотя на другую вещь, чем быстро умереть в режиме веб-запроса (например, я подозрительный на PDO).

В питон мира я видел в последнее время часть кода из Синкен, это хороший Nagios переписать в виде питона демонами, очень умный. См. http://www.shinken-monitoring.org/the-global-architecture/ & http://www.shinken-monitoring.org/wiki/official/development-hackingcode. Поскольку это инструмент мониторинга, вы наверняка найдете там очень хорошие идеи для некоторых демонских задач.

Теперь, могу ли я сделать предложение? Почему бы не использовать Shinken или Centreon в качестве планировщика для задач сбора данных? (И, может быть, скоро, что, надеюсь, на данный момент работает Centeron с двигателем shinken вместо двигателя nagios)? Это может быть полезно для обнаружения изменений во внешних данных, выпуск в fetchs и т.д.

Тогда для задач, которые должны быть выполнены (выборка данных, преобразование данных, хранение данных и т.д.), это работа с ETL , Одним из хороших инструментов с открытым исходным кодом является Talend ETL (Java). Существуют некоторые средства планирования и мониторинга для Talend, но не с открытым исходным кодом (сорта-с открытым исходным кодом, где вы должны платить-a-лицензию). Но добавление внешнего планировщика, такого как Nagios для задач, должно быть легким (я надеюсь). Вам нужно будет проверить, что memcached доступен в качестве механизма хранения для talend ETL или код вашего плагина.

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

Answer 4

Лучшая практика - использовать любую технологию, которую вы знаете лучше всего. Вы будете:

• реализации решения быстрее
• лучше отладить проблемы, которые работают в
• более легко оценить LIBS (или даже знать о них), которые могут разгрузить часть работы за вас
• имеют более легкое время, поддерживая и расширяя код

Реально, скорость и использование ресурсов будут относительно неважными, если у вас действительно нет реальных требований к производительности.

Answer 5

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

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

Таким образом, я запускал эти задачи в задании «cron», которое было периодически (перезапущено), но убедитесь, что вы не запускаете больше копий задач, чем планируете.

Работы Cron более надежны, чем демоны.

• хрон, который терпит неудачу, и завершает работу начнется в следующий раз он запланирован
• хрон работы, которая содержит утечки памяти выпустит свою память, когда она заканчивает свой бег в любом случае
• хрон, который имеет свой программное обеспечение, разработанное (библиотеки и т. д.), автоматически захватывает новые версии при последующем запуске без особых усилий.
• «cron» уже предоставляет сценарии запуска/выключения, которые ваша команда Ops может использовать для управления им, поэтому вам не нужно их переписывать. Ваша команда Ops уже знает, как управлять «cron», и умеет комментировать записи crontab, если они хотят временно отключить ее.