Codifica video distribuita - Gearman vs Beanstalkd

Question

Sto cercando di costruire un cluster di codifica video distribuito di poche decine di macchine. Ive non ha mai lavorato con una coda di messaggi prima, ma i 2 con cui ho iniziato a giocare sono stati Gearman e Beanstalkd.

Beanstalk sembra essere molto più semplice e facile da usare rispetto a Gearman, ma non è così ricco di funzionalità come.

Una cosa che non capisco è ... come si generano nuovi lavoratori su tutti i server? Ho intenzione di usare php. È semplice come eseguire worker.php in CLI con "&" e basta che si sieda lì in attesa di lavoro?

Ho notato che l'ingranaggio in realtà non uccide il processo dopo che un lavoro è finito, ma Beanstalk lo fa, quindi devo riavviare lo script dopo ogni lavoro, su ogni server.

Attualmente Im più inclini a utilizzare fagiolo magico, il flusso generale delle cose che ho previsto era:

Eseguire un minuziosamente cron su ogni server che controlla se ci sono quantità di lavoratori pre-definito in esecuzione. Se meno di quanto dovrebbe essere, genera nuovi processi di lavoro. Ogni processo richiederà circa 2-30 minuti.

Forse ho un difetto nella mia logica qui? Fammi sapere quale sarebbe un modo "migliore" o "corretto" per farlo?

Answer 1

Terminologia Userò solo per cercare di essere chiaro ... C'è il concetto di produttore e consumatore. Il produttore genera lavori che vengono messi in coda (cioè il servizio beanstalk) che viene poi letto da un consumatore.

Ci sono diversi modi per scrivere un consumatore. È possibile impostare ogni intervallo di tempo x tramite un cron job per eseguire l'attività o semplicemente avere un utente che esegue un ciclo while tramite php (o cosa si ha).

Dove installare il servizio dipende in realtà da ciò che si sta cercando. Per me normalmente installo il servizio su un consumatore o sulla sua scatola separata (a volte quest'ultimo è eccessivo a seconda delle esigenze).

Se si desidera la durabilità sul lato della coda, è necessario utilizzare il parametro binlog di Beanstalk (-b). Se succede qualcosa al tuo servizio beanstalk, questo ti permetterà di riavviare con una perdita minima di dati nelle code (se non ci sono informazioni). La durata sul lato produttore può derivare dall'avere più code da provare.