Perché utilizzare AMQP/ZeroMQ/RabbitMQ

Question

anziché scrivere la propria libreria.

Qui stiamo lavorando a un progetto che sarà un pool di server auto-dividente, se una sezione diventa troppo pesante, il gestore la dividerà e la metterà su un'altra macchina come processo separato. Avrebbe inoltre avvisato tutti i client connessi che influiscono sulla connessione al nuovo server.

Sono curioso di utilizzare ZeroMQ per la comunicazione tra server e tra processi. Il mio compagno preferirebbe tirare il suo. Sto guardando alla comunità per rispondere a questa domanda.

Sono un programmatore alle prime armi piuttosto me stesso e solo imparato a conoscere le code di messaggistica. Come ho cercato su Google e letto, sembra che tutti stiano utilizzando code di messaggi per ogni genere di cose, ma perché? Cosa li rende migliori rispetto alla scrittura della tua libreria? Perché sono così comuni e perché ce ne sono così tanti?

Answer 1

ciò che li rende meglio che scrivere la vostra libreria?

Quando tiri fuori la prima versione della vostra applicazione, probabilmente nulla: le vostre esigenze sono ben definiti e si svilupperà un sistema di messaggistica che si adatta alle vostre esigenze: piccolo elenco di funzionalità, piccolo codice sorgente ecc

questi strumenti sono molto utile dopo il primo rilascio, quando in realtà si deve estendere la vostra applicazione e aggiungere ulteriori funzionalità ad esso. Lasciate che vi dia un paio di casi di utilizzo:

• vostra applicazione dovrà parlare con una grande macchina endian (SPARC/PowerPC) da una macchina little endian (x86, Intel/AMD). Il sistema di messaggistica avuto qualche endian ordinazione presupposto: andare a risolvere il problema
• avete progettato la vostra applicazione in modo che non è un sistema binario di protocollo/messaggistica e ora è molto lento perché si spende la maggior parte del vostro tempo parsing esso (il numero di messaggi è aumentata e l'analisi è diventato un collo di bottiglia): adattarla in modo che possa trasportare binario/codifica fissa

• all'inizio avevi 3 macchina all'interno di una rete LAN, senza ritardi evidente tutto diventa per ogni macchina.il tuo cliente/capo/capo-diavolo-capo-diavolo si presenta e ti dice che installerai l'app su WAN che non gestisci - e poi inizierai ad 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 risposte, ma non tutte: si inviano alcuni parametri e si aspettano un foglio di calcolo come risultato invece di solo l'invio e riconosce, risalgono al codice e la spina a questa roba (e godere).

• alcuni messaggi sono critiche e non la ricezione/invio esigenze corretta backup/persistenza /. Perchè lo chiedi ? fini di controllo

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

è possibile implementare da soli, ma non si trascorre molto tempo a fare in questo modo: si avrà probabilmente sostituirlo in seguito comunque.

Answer 2

cosa li rende migliori rispetto alla scrittura della propria libreria?

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

persistenza in questo contesto significa che il middleware di messaggistica continua a non gestita messaggi in memoria permanente (su disco) nel caso in cui il server va giù; dopo un riavvio, i messaggi possono essere gestiti e non è necessario ritrasmettere (il mittente non sa nemmeno che c'era un problema). Transazionale significa che è possibile leggere messaggi da code diverse e scrivere messaggi in code diverse in modo transazionale, vale a dire che tutte le letture e le scritture hanno esito positivo o (se uno o più errori) nessuno ha esito positivo. Questo non è molto diverso dalla transazionale conosciuta dall'interfacciamento con i database e ha gli stessi vantaggi (semplifica la gestione degli errori, senza le transazioni, si dovrebbe assicurare che ogni singola lettura/scrittura abbia esito positivo e, se uno o più falliscono, si ha per ripristinare le modifiche che hanno avuto esito positivo).

Answer 3

Questo è molto simile a chiedere: perché usare un database quando si può scrivere il proprio?

La risposta è che l'utilizzo di uno strumento in uso da un po 'di tempo e ben compreso in molti casi d'uso diversi, si ripaga sempre più nel tempo e con l'evoluzione delle vostre esigenze. Questo è particolarmente vero se più di uno sviluppatore è coinvolto in un progetto. Vuoi diventare uno staff 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: la persistenza. Scrivere uno strumento per archiviare un messaggio su disco è facile. Scrivere un resistore che si adatta bene a e in modo stabile, in molti casi d'uso diversi, ed è gestibile, ed economico da supportare, è difficile. Se vuoi vedere qualcuno che si lamenta di quanto sia difficile, allora guarda: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

Comunque, spero che questo aiuti. Con tutti i mezzi scrivi il tuo strumento. Molte persone lo hanno fatto. Qualunque cosa risolva il tuo problema, va bene.

Answer 4

Sto pensando di utilizzare ZeroMQ me stesso - quindi ci siamo imbattuti in questa domanda.

Supponiamo per il momento che si avrà la possibilità di implementare un sistema di accodamento dei messaggi che soddisfa tutte le vostre esigenze. Perché dovresti adottare ZeroMQ (o altra libreria di terze parti) sull'approccio roll-your-own? Semplice - costo.

Supponiamo per un momento che ZeroMQ soddisfa già tutti i requisiti. Tutto ciò che deve essere fatto è integrarlo nella tua build, leggere alcuni documenti e quindi iniziare a usarlo. Deve essere molto meno impegnativo che rotolare il tuo. Inoltre, l'onere della manutenzione è stato trasferito a un'altra società. Dato che ZeroMQ è gratuito, è come se avessi cresciuto il tuo team di sviluppo per includere (parte) il team ZeroMQ.

Se gestisci un'attività di sviluppo software, allora penso che potresti bilanciare il costo/rischio dell'utilizzo di librerie di terze parti contro le tue personali e in questo caso, l'utilizzo di ZeroMQ potrebbe vincere a mani basse.

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

EDIT: mi sono imbattuto in questo video dagli sviluppatori ZeroMQ che parla di perché si dovrebbe usare ZeroMQ.

Answer 5

Se avete un po 'di tempo provatelo e sviluppate la vostra implemntazione! L'apprendimento di questo esercizio ti convincerà della saggezza dell'uso di una libreria già testata.

Answer 6

Prima di scrivere la propria libreria, leggere la guida 0MQ qui: http://zguide.zeromq.org/page:all

È probabile che si sia decidere di installare RabbitMQ, altrimenti si farà la libreria in cima ZeroMQ dal momento che hanno già fatto tutto il parti difficili