2010-07-08 14 views
12

Desidero un feedback sul fatto che le mie valutazioni e preoccupazioni siano corrette.DDS vs AMQP vs ZeroMQ

Sono stato reseaching tre, Data Distribution Service, AMQP e ZeroMQ per qualche ora per la creazione di un livello di trasporto dati in un datacenter. Tutti e tre sembrano promettenti, tuttavia ho riscontrato alcuni problemi di blocco in pochi.

Per dare un contesto, i miei requisiti sono:

  1. Scala FINO 500+ nodi fisici, 1000+ editori e gli abbonati.
  2. Supportare la consegna duratura dei messaggi per prendersi cura degli abbonati in errore.
  3. La velocità aggregata dovrebbe essere a nord di 1 milione di messaggi/sec

Problemi con AMQP:

  1. L'architettura Broker sembra essere un collo di bottiglia e punto centrale del fallimento di tutta l'installazione distribuzione. Posso complicare la distribuzione implementando una federazione e un cluster per migliorare le prestazioni e la disponibilità dei messaggi in sospeso, ma non sembrano ancora resistenti ai guasti.
  2. Le prestazioni per le code resistenti sembrano essere molto inferiori. La mia applicazione di esempio poteva solo sincronizzare i messaggi 6-7K/core/queue/application.

Problemi con ZeroMQ:

  1. La documentazione sembra essere un po 'che vogliono in profondità.
  2. Il comportamento del sistema per i messaggi in sospeso sembra causare problemi nel modello di comunicazione PUB/SUB. Si prega di fare riferimento a: How zeromq handles slow consumers with PUB/SUB mode

OpenSplice DDS: non ho trovato nulla manca nel protocollo DDS tranne che per l'adozione del settore. Vorrà conoscere una recensione di prima mano su questo prodotto in termini di stabilità, prestazioni o limitazioni.

+0

Affronterò la domanda in modo approfondito ma per ora voglio suggerire di aggiungere il tag "data-distribution-service" invece di "dds". Quest'ultimo sembra essere stato dirottato dalla programmazione grafica. –

+0

Grazie Holger, ho aggiornato i tag. – Kisalay

+2

Solo per rendere la discussione collegata ZeroMQ più sottile: per PUB/SUB, esiste effettivamente un limite per sottoscrittore preimpostato sulla dimensione della coda dei messaggi, su cui vengono eliminati i messaggi. Ma esiste anche l'opzione ZMQ_SWAP, con la quale è possibile abilitare lo scambio dei messaggi sui dischi. Citando [1] "Tuttavia, c'è una via d'uscita. ØMQ fornisce qualcosa chiamato >> scambio <<, che è un file del disco che contiene messaggi che non possiamo memorizzare nella coda" [1] http: // zguide.zeromq.org/chapter:all – ron

risposta

12

Sono sorpreso delle vostre preoccupazioni sull'adozione di DDS OpenSplice. OpenSplice DDS è oggi implementato su diversi sistemi mission e business critical come i sistemi di gestione del combattimento navale, i veicoli militari, il controllo del traffico aereo e la gestione, la metropolitana, all'automercato ad alta frequenza. Solo per darti un altro po 'di informazioni che dovrebbero darti rassicurazioni su w.r.t. l'adozione della tecnologia, lo standard OMG DDS (lo standard implementato da OpenSplice DDS) è stato raccomandato da EUROCAE per lo scambio di piani di dati di volo tra i vari centri paneuropei.

Fatemi sapere se avete ulteriori domande sull'adozione o sulla tecnologia.

-AC

+2

Yea e io abbiamo guardato il codice di OpenSplice ed è orribile. Anche l'API è un grosso casino ed è complicato da configurare. OpenSplice è stato scritto da persone che non capiscono nulla dei principi di progettazione del software. E potrebbe essere adottato da molte aziende perché funziona, ma non è certo la strada da percorrere se si vuole evolvere nel futuro. – fonZ

1

Date un'occhiata a this pagina. Oggi molte industrie e aziende utilizzano DDS.