Многопроцессорная обработка Python с очередью против ZeroMQ IPC

Я занят написанием приложения на Python с использованием ZeroMQ и реализацией варианта шаблона Majordomo, как описано в ZGuide .

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

Я думал о двух способах:

1. Создайте рабочих, которые только для регистрации и использовать транспорт ZeroMQ IPC
2. Использовать многопроцессорность с очередью

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

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

Мне нравится подход использования стандартных инструментов, например, предложенный Джонатаном. Вы не упомянули, над какой ОС вы работаете, но другой альтернативой, которая следует тому же духу, может быть использование стандартного модуля регистрации Python вместе с ним logging.handlers.SysLogHandlerи отправка сообщений регистрации службе rsyslog (доступной на любом linux / unix, но я Я думаю, что есть также вариант Windows , но я никогда не использовал его).

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

Еще одним преимуществом этого подхода является то, что ваш продукт будет гораздо лучше интегрироваться с другими инструментами sysadmin, созданными поверх syslog. И это даже не потребует от вас написания какого-либо кода, чтобы получить такую ​​возможность.

Возможно, вы захотите рассмотреть третий вариант реализации удаленного ведения журнала. Если вы используете стандартный модуль ведения журналов Python, вы можете рассмотреть возможность использования этого logging.QueueHandlerкласса в своих рабочих, клиентах и ​​посредниках, а также logging.QueueListenerв своем процессе удаленной регистрации.

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

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

Это принципиально разные подходы, каждый из которых имеет свои плюсы и минусы, которые вы, скорее всего, увидите на более поздней стадии разработки:

Я думал о двух способах:

1. Создайте рабочих, которые только для регистрации и использовать транспорт ZeroMQ IPC
2. Использовать многопроцессорность с очередью

Один из способов, которым вы могли бы попытаться, - это иметь дополнительного работника регистрации, как в подходе 1. Вы могли бы позволить своим работникам регистрироваться в кластере ведения журналов memcache, и работник регистрации отслеживает текущую загрузку ресурсов и после выхода из заданного параметра загрузки ресурсов, работник регистрируется на устройстве с ограниченным IOP (например, на жестком диске).

Мне также нравится подход Джонатана с оговоркой, что я тоже в основном использую Python 2.x, и что вам, вероятно, придется настроить свой собственный бэкэнд журналирования, чтобы действительно увеличить производительность.

Поправьте меня, если я ошибаюсь, но я полагаю, что вы выполняете какую-то действительно интенсивную работу с данными, а IOP хранилища является вашим узким местом.

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

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