come decidere quando utilizzare la replica del database rispetto alle applicazioni REST personalizzate e ai broker dei messaggi (pub / sub)

3

Abbiamo una soluzione distribuita che è attualmente in fase di progettazione. Ci sono alcuni punti di integrazione in cui alcune applicazioni richiedono dati da qualcun altro e viceversa. Potremmo risolvere scrivendo le interfacce REST e fornendo funzionalità CRUD in modo che le app possano condividere i dati tra loro. Oppure possiamo usare qualcosa come nanomsg o zeroMQ per inviare messaggi avanti e indietro.

Abbiamo anche requisiti H / A in cui vogliamo fare il master per padroneggiare la replica tra i server db primari e secondari per garantire che se uno scende, l'altro può dare il calcio d'inizio.

Ecco la domanda. Alcuni membri del team pensano che dovremmo scegliere un metodo di condivisione dei dati, come il master per la masterizzazione della replica ... e basta usarlo su tutta la linea per "condividere" i dati. È vero che possiamo farlo, ma penso che ogni caso dovrebbe essere analizzato e trattato separatamente in base a criteri specifici come:

  1. i database in questione sono identici? se lo sono, il master da padroneggiare è appropriato, come nel nostro scenario High Availability.
  2. nel caso di sistemi disparati, quanti dati stiamo passando avanti e indietro? se sono molti dati ... forse un messaggio bus è migliore. invia semplicemente una notifica per dire "c'è un cambiamento ... ecco l'id di modifica. Vai a prenderlo".
  3. Quanto spesso cambiano i dati? Questo importa? Penso che sia una API REST sia un bus dei messaggi saranno in grado di gestire molte transazioni.

Non sono sicuro di cos'altro pensare. Sembra che la creazione di una soluzione di message bus sia molto più impegnativa di una REST api in ogni database. Ma potrei sbagliarmi. Quali altre cose dovremmo prendere in considerazione?

Grazie.

    
posta dot 27.02.2015 - 16:45
fonte

1 risposta

3

Se è necessario condividere (leggere e scrivere) tutti i dati e utilizzare le transazioni, quando si utilizza solo l'accesso condiviso al database. Se hai bisogno di alta disponibilità, valuta l'ipotesi di utilizzare la replica master-slave . Non andare solo ciecamente con il master-master, pensa attentamente agli svantaggi :

  • Most multi-master replication systems are only loosely consistent, i.e. lazy and asynchronous, violating ACID properties.
  • Eager replication systems are complex and increase communication latency.
  • Issues such as conflict resolution can become intractable as the number of nodes involved rises and latency increases.

Contro REST :

  • In realtà devi implementarlo, testarlo e supportarlo.
  • Nessuna transazione su più risorse, a meno che non si reinventino le transazioni sul livello API, che è l'idea peggiore possibile.

Code dei messaggi contro :

  • Non adatto per la condivisione di dati. Le MQ sono buone per la comunicazione tra processi asincrona: invocazione di comandi, eventi di attivazione, ecc.
  • Ancora una volta, è necessario implementare, testare e supportare i gestori di messaggi, poiché i dati non vengono magicamente condivisi solo dopo essere stati messi in coda.

Tuttavia, se hai bisogno di condividere alcune parti dei tuoi dati, e le transazioni multi-risorse non sono necessarie, quando REST (o forse JSON-RPC) potrebbe essere una soluzione migliore.

Tuttavia, MQ sarà una cattiva soluzione, dal momento che, come ho detto, risolve un altro insieme di problemi.

La risposta alla tua domanda dipende da cosa hai effettivamente bisogno:

  • Condivisione di tutti i dati così come sono, potendo utilizzarli nelle transazioni - DB condiviso
  • Condivisione di alcuni dati in modo granulare uniforme (CRUD) - REST
  • Operazioni che coinvolgono varie parti di dati e / o logica non banale - JSON-RPC
  • Comunicazione inter-processo asincrona - Code di messaggi
risposta data 27.02.2015 - 21:20
fonte