I dati di caching tra sistemi indipendenti ma interagenti sono ok?

Question

I dati di caching tra sistemi indipendenti ma interagenti sono ok?

#1 da (2 voti)
#2 da (0 voti)

1

Abbiamo due prodotti che chiamiamo X e Y. Product-X è stato creato e ha numerosi clienti nei continenti, mentre lo sviluppo di Product-Y è iniziato qualche anno fa e deve ancora godere di qualsiasi cliente.

Ci siamo imbattuti in uno scenario in cui dobbiamo sincronizzare i dati e le azioni tra entrambi i sistemi. Questo può essere fatto in qualsiasi momento, ad es. i client possono utilizzare i sistemi da soli e in un secondo momento vorrebbero sincronizzarli.

Ora ospiteremo sempre Product-X sulle nostre server farm. Tuttavia i client possono o meno farlo per Product-Y e ospitarli localmente in proprio server farm. Sono molto nuovo nella progettazione di sistemi, quindi sto chiamando questi sistemi distribuiti che potrebbero non essere il termine giusto.

Entrambi i prodotti sono diversi e avranno sempre il proprio database e struttura indipendentemente dal fatto che si trovino nello stesso ambiente o nella server farm del cliente.

Esempio

Sincronizzazione dei dati in base agli eventi, ad es. se qualcuno crea qualcosa in Product-X, deve essere creato anche in Product-Y ma seguendo diversi passaggi logici e lo stesso per quando qualcosa viene creato o aggiornato in Product-Y.

Soluzione possibile

Qualsiasi operazione che si verifica in qualsiasi sistema invierà i dati all'altro sistema utilizzando servizi generici e l'altro sistema deciderà cosa fare con esso.
Crea una cache di dati su entrambe le estremità, ad es. nelle tabelle SQL. Ciò significa che entrambi i sistemi non si chiederanno mai dati a vicenda o se hanno bisogno di qualcosa invieranno solo un flag e riceveranno una richiamata con dati.
Entrambi i sistemi avranno endpoint (servizi WCF) per connettersi l'un l'altro.

Domanda

Va bene conservare una cache di dati, se no, quale sarebbe il design giusto per questo scenario?

design database architecture distributed-computing data-replication

posta Mathematics 05.06.2017 - 09:57

fonte

2 risposte

Leggi altre domande sui tag design database architecture distributed-computing data-replication

Come convalidare molti campi JSON senza ingombrare il codice con if-checks su ogni campo? Modellazione di entità di database relazionali in un linguaggio funzionale

score 2 · Answer 1

I tuoi requisiti sono:

hai due prodotti indipendenti, che gestiscono i dati che si sovrappongono (in base ai tuoi primi due paragrafi)
i due prodotti rimarranno indipendenti con i propri database e verrebbero generalmente eseguiti su server distinti con il proprio database (secondo il terzo e il quarto paragrafo)
vuoi trovare un meccanismo di sincronizzazione dei dati tra i due sistemi

Sembra che questi requisiti condividano molti punti in comune con l' architettura dei microservizi , anche se ognuno dei tuoi sistemi potrebbe in realtà essere un monolito tutto suo. La chiave è liberamente accoppiata e interagente.

Pertanto potresti essere interessato ai modelli di microservizi comuni , che offrono soluzioni a questi problemi. In particolare, è abbastanza comune in questo mondo avere un database per servizio (per sistema nel caso) che rimangono sincronizzati utilizzando un'architettura basata su eventi .

Ora la tua domanda è fondamentalmente guardando il modo migliore per comunicare gli eventi; dovresti:

collega gli endpoint tramite l'invocazione remota ,
o utilizza la messaggistica con una coda di messaggi (ad esempio RabbitMQ) o flussi di eventi (ad esempio Kafka) ,
o utilizza approcci specifici del dominio

Fondamentalmente, tutti e tre hanno le proprie forze specifiche (vedi link forniti). Personalmente e intuitivamente, opterei per un flusso di eventi e organizzerei sviluppi futuri su questo paradigma. Ma non ne so abbastanza sul tuo contesto, quindi non scommettere su di esso senza fare prima la tua analisi.

L'ultimo punto con la cache, è un po 'diverso. Qui non si tratta di comunicazione, ma di se replicare o meno i dati. Se i dati che si sovrappongono sono lì solo per attivare alcune azioni, non è necessario replicare (questo sarebbe ancora più favorevole ai flussi di eventi). Se i dati che si sovrappongono sono complementari e vengono spesso utilizzati insieme, è possibile replicarli, in base al motto "una replica vale più di milioni di query aggiuntive". Ma ancora, spetta a te analizzare come migliorare il tempo di balletto rispetto allo spazio.

score 0 · Answer 2

Per come la vedo io, non c'è niente di sbagliato in ciò che stai cercando di ottenere. In ogni caso, proverei prima a cercare un collo di bottiglia, sai se avrai problemi di latenza / prestazioni? Considera che stai trasferendo il carico di lavoro dal processo di accesso ai dati al processo di modifica dei dati, potresti aver appena creato un problema nel tentativo di risolverne uno che ancora non sai di avere.

Valuta attentamente il tempo richiesto per la scrittura dei dati e il tempo richiesto per la lettura dei dati. Valutare anche quali dati sono un buon candidato per il caching; questo di solito significa bassa frequenza di scrittura e alta frequenza di lettura.