Python Multiprocessing con Queue vs ZeroMQ IPC

Sono impegnato a scrivere un'applicazione Python usando ZeroMQ e implementare una variante del modello Majordomo come descritto nella ZGuide .

Ho un broker come intermediario tra un gruppo di lavoratori e clienti. Voglio fare una registrazione approfondita per ogni richiesta che arriva, ma non voglio che il broker perda tempo a farlo. Il broker dovrebbe passare quella richiesta di registrazione a qualcos'altro.

Ho pensato a due modi: -

1. Creare lavoratori che sono solo per la registrazione e utilizzare il trasporto IPC ZeroMQ
2. Utilizzare il multiprocessing con una coda

Non sono sicuro di quale sia il migliore o il più veloce per quella materia. La prima opzione mi consente di utilizzare le classi base di lavoratori correnti che uso già per i lavoratori normali, ma la seconda opzione sembra più rapida da implementare.

Vorrei qualche consiglio o commento su quanto sopra o possibilmente una soluzione diversa.

Mi piace l'approccio dell'uso di strumenti standard come quello proposto da Jonathan. Non hai menzionato su quale sistema operativo stai lavorando, ma un'altra alternativa che segue quello stesso spirito potrebbe essere quella di utilizzare il modulo di registrazione standard di Python insieme logging.handlers.SysLogHandlere inviare i messaggi di registrazione al servizio rsyslog (disponibile su qualsiasi Linux / Unix, ma io penso che ci sia anche un'opzione di Windows , ma non l'ho mai usata).

In sostanza, l'intero sistema implementa la stessa cosa a cui stai pensando. Il processo locale accoda il messaggio di registro per essere gestito / elaborato / scritto da qualcun altro. In questo caso, qualcun altro ( rsyslog) è un servizio ben noto e collaudato che ha molte funzionalità e flessibilità integrate.

Un altro vantaggio di questo approccio è che il tuo prodotto si integrerà molto meglio con altri strumenti sysadmin basati su syslog. E non richiederebbe nemmeno di scrivere alcun codice per ottenere questa opzione.

È possibile prendere in considerazione una terza possibilità per l'implementazione della registrazione remota. Se si utilizza il modulo di registrazione Python standard, è possibile prendere in considerazione l'utilizzo della logging.QueueHandlerclasse nei propri lavoratori, client e broker e della logging.QueueListenerclasse nel processo di registrazione remoto.

Invece di utilizzare il normale Python multiprocessing.Queuecome trasporto tra i processi dell'applicazione e il processo di registrazione, implementare la propria Queueclasse di sostituzione utilizzando ZeroMQ con la digitazione duck per fare in modo che la classe sia un sostituto drop-in per lo standard Python Queue. In questo modo l'applicazione sarà in grado di funzionare inalterata in qualsiasi ambiente da un singolo computer multi-core attraverso data center distribuiti.

Riassumendo, utilizzare un logger Python standard con a QueueHandlerin tutti i tuoi dipendenti, clienti e broker e creare un processo indipendente basato sui gestori QueueListenerPython loggingdi tua scelta per gestire il pesante sollevamento della registrazione.

Si tratta di approcci radicalmente diversi, ognuno con i propri insiemi di pro e contro, che molto probabilmente vedrai in una fase successiva di sviluppo:

Ho pensato a due modi: -

1. Creare lavoratori che sono solo per la registrazione e utilizzare il trasporto IPC ZeroMQ
2. Utilizzare il multiprocessing con una coda

Un modo in cui è possibile provare è disporre di un lavoratore di registrazione aggiuntivo, come nell'approccio 1. È possibile consentire ai propri lavoratori di accedere a un cluster di registrazione memcache e il lavoratore di registrazione controlla il carico di risorse corrente e al momento del decadimento di un determinato parametro di caricamento delle risorse, il il lavoratore accede a un dispositivo limitato IOP (ad es. disco rigido).

Mi piace anche l'approccio di Jonathan con l'avvertenza che anche io uso principalmente Python 2.xe che probabilmente dovresti impostare il tuo back-end di registrazione per spingere davvero le prestazioni.

Correggimi se sbaglio, ma la mia opinione è che stai svolgendo un compito davvero ad alta intensità di dati, con IOP di archiviazione come collo di bottiglia.

Un modo conveniente sarebbe comunque quello di consentire al broker di effettuare la brokerageregistrazione, nella forma descritta, con tutti gli svantaggi di un'istanza del broker centrale. Ad esempio, se il broker ha una domanda così elevata che non riesce mai a respirare per riportare i registri memorizzati nella memoria, è necessario adottare un altro approccio.

Alla fine potresti finire con un modello senza broker. Cioè con i lavoratori che gestiscono il proprio lavoro tra di loro. In un semplice esempio, tramite un algoritmo distribuito round-robin .