Perché usare AMQP / ZeroMQ / RabbitMQ

Question

invece di scrivere la tua libreria.

Stiamo lavorando a un progetto che sarà un pool di server che si divide da solo, se una sezione diventa troppo pesante, il manager lo dividerebbe e lo inserirà su un altro computer come processo separato. Avrebbe inoltre avvisato tutti i client connessi che ciò influenza la connessione al nuovo server.

Sono curioso di usare ZeroMQ per le comunicazioni tra server e tra processi. Il mio partner preferirebbe farlo da solo. Sto cercando la community per rispondere a questa domanda.

Sono un programmatore abbastanza principiante e ho appena imparato a conoscere le code di messaggistica. Come ho cercato su Google e letto, sembra che tutti stiano usando le code di messaggistica per ogni sorta di cose, ma perché? Cosa li rende meglio che scrivere la tua biblioteca? Perché sono così comuni e perché ce ne sono così tanti?

Answer 1

  

cosa li rende meglio che scrivere la tua libreria?

Quando lanci la prima versione della tua app, probabilmente nulla: le tue esigenze sono ben definite e svilupperai un sistema di messaggistica adatto alle tue esigenze: piccolo elenco di funzionalità, piccolo codice sorgente ecc.

Questi strumenti sono molto utili dopo alla prima versione, quando in realtà devi estendere la tua applicazione e aggiungere più funzionalità ad essa. Lascia che ti dia alcuni casi d'uso:

• la tua app dovrà parlare con una grande macchina endian (sparc / powerpc) da una piccola macchina endian (x86, intel / amd). Il tuo sistema di messaggistica aveva un presupposto per l'ordinamento di endian: vai e correggilo
• hai progettato la tua app in modo che non sia un protocollo binario / un sistema di messaggistica e ora è molto lenta perché passi la maggior parte del tempo a analizzarla (il numero di messaggi è aumentato e l'analisi è diventata un collo di bottiglia): adattala in modo che possa trasporto binario / codifica fissa

• all'inizio avevi 3 macchine all'interno di una lan, senza ritardi evidenti tutto arriva su ogni macchina. il tuo cliente / capo / capo-diavolo-capo si presenta e ti dice che installerai l'app su WAN che non gestisci - e quindi inizi a avere problemi di connessione, cattiva latenza ecc. devi archiviare il messaggio e riprovare l'invio più tardi: torna al codice e collega questa roba (e divertiti)

• i messaggi inviati devono avere delle risposte, ma non tutte: invii alcuni parametri e ti aspetti un foglio di calcolo come risultato invece di inviare e riconoscere, tornare al codice e collegare questo materiale (e divertiti .)

• alcuni messaggi sono fondamentali e la ricezione / invio necessita di backup / persistenza adeguati /. Perchè lo chiedi ? scopi di controllo

E molti altri casi d'uso che ho dimenticato ...

Puoi implementarlo da solo, ma non perdere molto tempo a farlo: probabilmente lo sostituirai in seguito in ogni caso.

Answer 2

È molto simile a chiedere: perché usare un database quando puoi scrivere il tuo?

La risposta è che l'uso di uno strumento che esiste da un po 'di tempo ed è ben compreso in molti casi d'uso diversi, ripaga sempre di più nel tempo e con l'evoluzione delle vostre esigenze. Ciò è particolarmente vero se più di uno sviluppatore è coinvolto in un progetto. Vuoi diventare personale di supporto per un sistema di accodamento se passi a un nuovo progetto? L'uso di uno strumento impedisce che ciò accada. Diventa il problema di qualcun altro.

Caso in questione: persistenza. Scrivere uno strumento per archiviare un messaggio sul disco è facile. Scrivere un resistore che ridimensiona e funzioni bene e in modo stabile, in molti casi d'uso, è gestibile e economico da supportare, è difficile. Se vuoi vedere qualcuno lamentarsi di quanto sia difficile, guarda questo: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

Comunque, spero che questo aiuti. Scrivi a tutti i costi il ??tuo strumento. Molte persone l'hanno fatto. Qualunque cosa risolva il tuo problema, va bene.

Answer 3

Sto pensando di usare ZeroMQ da solo, quindi mi sono imbattuto in questa domanda.

Supponiamo per il momento che tu abbia la possibilità di implementare un sistema di accodamento dei messaggi che soddisfi tutti i tuoi requisiti. Perché dovresti adottare ZeroMQ (o altra libreria di terze parti) sull'approccio roll-your-own? Semplice - costo.

Supponiamo per un momento che ZeroMQ soddisfi già tutti i tuoi requisiti. Tutto ciò che deve essere fatto è integrarlo nella tua build, leggere alcuni documenti e quindi iniziare a usarlo. Dev'essere molto meno sforzo che farti il ??tuo. Inoltre, l'onere della manutenzione è stato spostato su un'altra società. Poiché ZeroMQ è gratuito, è come se avessi appena cresciuto il tuo team di sviluppo per includere (parte del) team ZeroMQ.

Se gestissi un'attività di sviluppo software, penso che bilanceresti il ??costo / rischio dell'utilizzo di librerie di terze parti contro il lancio delle tue e, in questo caso, l'utilizzo di ZeroMQ vincerebbe a mani basse.

Forse tu (o meglio il tuo partner) soffri, come fanno molti sviluppatori, del " Not Inventato qui " sindrome? In tal caso, modifica il tuo atteggiamento e rivaluta l'uso di ZeroMQ. Personalmente, preferisco di gran lunga i vantaggi dell'atteggiamento di Orgogliosamente trovato altrove. Spero di poter essere orgoglioso di trovare ZeroMQ ... il tempo lo dirà.

EDIT: mi sono imbattuto in questo video degli sviluppatori ZeroMQ che parla di perché dovresti usare ZeroMQ.

Answer 4

  

cosa li rende meglio che scrivere la tua libreria?

I sistemi di accodamento dei messaggi sono transazionali, che è concettualmente facile da usare come client, ma difficile da implementare come implementatore, soprattutto considerando le code persistenti. Potresti pensare di riuscire a scrivere una libreria di messaggistica rapida, ma senza transazioni e persistenza non avresti tutti i vantaggi di un sistema di messaggistica.

La persistenza in questo contesto significa che il middleware di messaggistica mantiene i messaggi non gestiti nella memoria permanente (su disco) nel caso in cui il server si spenga; dopo un riavvio, i messaggi possono essere gestiti e non è necessaria alcuna ritrasmissione (il mittente non sa nemmeno che si è verificato un problema). Transazionale significa che è possibile leggere messaggi da diverse code e scrivere messaggi su diverse code in modo transazionale, il che significa che tutte le letture e le scritture hanno esito positivo o (se una o più falliscono) nessuna ha esito positivo. Questo non è molto diverso dalla transazionalità conosciuta dall'interfaccia con i database e ha gli stessi vantaggi (semplifica la gestione degli errori; senza transazioni, dovresti assicurarti che ogni singola lettura / scrittura abbia successo e se uno o più falliscono, hai per ripristinare quei cambiamenti riusciti).

Answer 5

Prima di scrivere la tua libreria, leggi la Guida 0MQ qui: http://zguide.zeromq.org/ pagina: tutto

È probabile che deciderai di installare RabbitMQ, oppure farai la tua libreria su ZeroMQ poiché hanno già fatto tutte le parti difficili.

Answer 6

Se hai un po 'di tempo, prova e implementa la tua implementazione! Gli apprendimenti di questo esercizio ti convinceranno della saggezza di usare una libreria già testata.