Esiste un motivo valido per utilizzare un server basato su AMQP su qualcosa come beanstalkd o redis?

Question

Sto scrivendo un pezzo per un progetto che è responsabile per l'elaborazione di attività al di fuori del server di dati di fronte all'applicazione principale, che è scritto in javascript utilizzando Node.js. Ha bisogno di gestire le attività che sono pianificate in futuro e potenzialmente gestiscono attività che sono "in questo momento". Il "giusto ora" significa solo che la prossima volta che un lavoratore diventa disponibile, opererà su quell'attività, in modo che il bit non abbia importanza. I lavoratori parleranno tutti con risorse esterne, un esempio di lavoro sarebbe inviare un'e-mail. Siamo un piccolo negozio e non abbiamo un sacco di risorse quindi una cosa che non voglio fare è iniziare a mescolare le lingue a questo punto del processo, e ho già visto che il Node può farlo abbastanza facilmente per noi, quindi è quello con cui andremo a meno che non vedo una ragione convincente per non iniziare prima di iniziare a programmare, che è presto.

Detto questo, non posso dire se c'è un motivo valido per utilizzare un server basato su AMQP, come OpenAMQ o RabbitMQ sopra qualcosa come Kue o Beanstalkd con un cliente nodo. Quindi, eccoci:

C'è un motivo valido per utilizzare un server basato su AMQP su qualcosa come beanstalkd o redis con Kue? In caso affermativo, quale server basato su AMPQ si adatta meglio all'architettura che ho predisposto? Se no, quale soluzione nosql (beanstalkd, redis/Kue) sarebbe più facile da configurare e più veloce da implementare?

Answer 1

FWIW, non accetto ancora la mia risposta, ho intenzione di spiegare cosa ho deciso e perché. Se non ricevo risposte che sembrano migliori di quelle che ho deciso, accetterò le mie in seguito.

Ho deciso su Kue. Supporta più worker in esecuzione in modo asincrono e con cluster può sfruttare i sistemi multicore. È facilmente estendibile per fornire sicurezza. E 'sostenuto con Redis, che viene utilizzato in tutto per questa cosa esatta, così io so che non sono il backup mio server processo di lavoro con software non dimostrata (che non vuol dire che tutti gli altri sono non provati.)

Il più motivi convincenti che ho scelto Kue è che fornisce un API JSON in modo che le applicazioni client (il primo client sarà un'applicazione basata sul Web, ma stiamo progettando anche di creare app per smartphone) che possano aggiungere facilmente posti di lavoro senza passare attraverso l'istanza del nodo di fronte all'applicazione principale, quindi posso essere totalmente fuori dal resto del mio team mentre scrivo questo. Non ho bisogno di un percorso, non ho bisogno di nulla, ed è tutto fornito per me quindi non ho bisogno di scrivere nulla per supportare questo. Questo ha un altro vantaggio, con un'estensione per fornire sicurezza l/p solo i client autorizzati possono aggiungere lavori, quindi non devo esporre direttamente il mio server redis alle applicazioni client. Ha anche una console web integrata e l'API consente al client di ritrarre molto facilmente gli elenchi di lavori associati a un determinato utente, in modo che possiamo mostrare all'utente tutte le attività pianificate in una bella vista del calendario con 0 sforzo da parte mia .

L'altro motivo convincente è la mancanza di una curva di apprendimento ripida associata all'ottenere redis e Kue andando per me. Ho creato i redis in passato e Kue è semplice ed efficace.

Sì, sono uno sviluppatore pigro, ma sono il buon tipo di sviluppatore pigro.

UPDATE:

ce l'ho a lavorare e fare i lavori, il throughput è sorprendente. Ho diviso la logica di marshalling delle attività nella propria istanza di nodo, in pratica tutto ciò che devo fare è distribuire il mio repository su una nuova macchina ed eseguire il nodo task-server.js per ridimensionare i miei dipendenti. Potrei aver bisogno di aggiungere qualche altro lavoro alla ricerca di chiamate a Kue, a causa di come ho implorato alcune cose, ma sarà facile.