Python Multiprocessing con Queue vs ZeroMQ IPC

Mi piace l'approccio all'uso di strumenti standard come quello proposto da Jonathan. Non hai menzionato il sistema operativo su cui stai lavorando, ma un'altra alternativa che segue lo stesso spirito potrebbe essere quella di utilizzare il modulo di registrazione standard di Python insieme a logging.handlers.SysLogHandler e inviare i messaggi di registrazione a rsyslog servizio (disponibile su qualsiasi linux / unix, ma penso che ci sia anche una opzione windows , ma non l'ho mai usato).

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

Un altro vantaggio di questo approccio è che il tuo prodotto si integrerà molto meglio con altri strumenti di sysadmin che sono costruiti su syslog. E non richiederebbe nemmeno che tu scriva alcun codice per ottenere quell'opzione.

Potresti considerare una terza possibilità per implementare la registrazione remota. Se utilizzi il modulo di registrazione Python standard, puoi prendere in considerazione l'utilizzo della classe logging.QueueHandler nei tuoi worker, client e broker e la classe logging.QueueListener nel tuo processo di registrazione remota.

Invece di usare il normale Python multiprocessing.Queue come trasporto tra i processi dell'applicazione e il processo di registrazione, implementa la tua classe di sostituzione Queue utilizzando ZeroMQ con digitazione anatra per fare in modo che la tua classe sia una sostituzione 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 tramite data center distribuiti.

Per riassumere, usa un logger Python standard con una QueueHandler in tutti i tuoi lavoratori, clienti e broker e crea un processo indipendente basato su QueueListener e il% handler di Python logging di tua scelta per gestire il sollevamento pesante della registrazione.

Questi sono approcci radicalmente diversi, ciascuno con le sue serie di pro e contro, che molto probabilmente vedrai in una fase successiva dello sviluppo:

I have thought of two ways :-

1. Create workers that are only for logging and use the ZeroMQ IPC transport
2. Use Multiprocessing with a Queue

Un modo che potresti provare è avere un addetto alla registrazione aggiuntivo, come nell'approccio 1. Puoi consentire ai tuoi lavoratori di accedere a un cluster di registrazione memcache e l'operatore di registrazione monitora il carico di risorse corrente e dopo aver declassato un determinato parametro di caricamento della risorsa, il lavoratore accede a un dispositivo IOP limitato (ad es. hard disk).

Mi piace anche l'approccio di Jonathan con l'avvertenza che anch'io utilizzo principalmente Python 2.x e che probabilmente dovresti configurare il tuo backend di log in modo da spingere davvero la busta delle prestazioni.

Correggimi se ho torto, ma è mia opinione che tu stia svolgendo un compito veramente intenso in termini di dati, con gli IOP di archiviazione come il collo di bottiglia.

Un modo conveniente sarebbe comunque lasciare che il broker esegua la registrazione di brokerage - nel modulo come descritto- con tutti gli svantaggi di un'istanza del broker centrale. Ad esempio, se il broker ha una domanda così elevata da non riuscire mai a trovare spazio per scrivere i registri memcached in memoria, è necessario adottare un altro approccio.

Alla fine potresti finire con un modello senza broker. Questo è con gli operai che gestiscono il loro lavoro tra di loro. In un semplice esempio, attraverso un algoritmo Distributed round-robin .