Багатопроцесорна робота 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 з a QueueHandlerдля всіх ваших працівників, клієнтів та посередників і створіть незалежний процес на основі QueueListenerта обраних loggingвами обробників Python для обробки важкого піднімання лісозаготівлі.

Це докорінно різні підходи, кожен з яких має свої плюси і мінуси, які, швидше за все, ви побачите на наступному етапі розвитку:

Я продумав два способи: -

1. Створіть працівників, які призначені лише для ведення лісозаготівлі та використання транспорту ZeroMQ IPC
2. Використовуйте багатопроцесорну чергу з чергою

Один із способів, який ви можете спробувати, - це мати додатковий працівник лісозаготівлі, як підхід 1. Ви можете дозволити вашим працівникам увійти до кластера реєстрації записів, а працівник журналу контролює поточне завантаження ресурсів та обманувши заданий параметр завантаження ресурсу, працівник записує на обмежений пристрій ВОП (наприклад, жорсткий диск).

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

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

Зручним способом все-таки було б дозволити брокеру робити brokerageжурнал - у формі, як описано - з усіма недоліками центрального екземпляра брокера. Наприклад, якщо брокер користується настільки високим попитом, що він ніколи не отримує дихальної кімнати, щоб записати складені журнали назад у сховище, вам потрібно буде скористатися іншим підходом.

Ви, зрештою, можете поставити модель без брокерів. Тобто з працівниками, які керують своєю роботою між собою. На простому прикладі, за допомогою алгоритму розподіленого кругового обертання .