Perché abbiamo bisogno di database multi-leader?

1. Supporta le scritture in più data center per aumentare le prestazioni tra i data center.
2. Tolleranza dei problemi di rete nei data center.
3. Funzionamento indipendente di tutti gli altri data center anche in caso di guasto di un data center

Come dovremmo gestire i conflitti di scrittura tra i leader? Collisione di chiavi con incremento automatico? Correggi i dati incasinati su più leader a causa di bug o problemi? e altro ancora

Il modo più semplice per risolvere un problema è non provare dolore

Come non avere conflitti in multi-leader?

Se ci assicuriamo che la scrittura a un particolare leader passi sempre attraverso lo stesso leader, allora non si verificheranno conflitti. Ciò sta aumentando le prestazioni di scrittura nei data center, ma cosa succede se un data center fallisce, alla fine dobbiamo affrontare i conflitti :(

Modi per affrontare i conflitti

Ora ci sono due modi per risolvere i conflitti

1. L'applicazione risolve i conflitti: l'applicazione rileva i conflitti e uno snippet di codice li risolve o il database può farlo. Uno dei modi è la tecnica last-to-write wins (LWW).
   Fatemi sapere nei commenti se volete un blog per discutere le varie tecniche. Sarei felice di farlo :)
2. L'utente risolve i conflitti: memorizza tutta la versione del conflitto e la prossima volta che l'utente legge i dati, richiede all'utente e riscrive il risultato nel database.

Ogni nodo scrive da un nodo e inoltra quelle scritture a un altro nodo

Un nodo radice designato inoltra le scritture a tutti gli altri nodi.

In tali architetture, esiste la possibilità che porti a cicli di replica infiniti. Stanno girando all'infinito su tutti i nodi.

Come evitare cicli di replica infiniti?

Ogni nodo ha un identificatore univoco e il registro di replica è contrassegnato con gli identificatori di tutti i nodi attraverso i quali viene passato.
E ogni volta che un nodo riceve una replica che ha il suo identificatore, la modifica dei dati viene ignorata poiché sa che è già stata elaborata e viene impedito il ciclo infinito

Ma c'è un altro problema qui, un singolo punto di errore.

Se un nodo fallisce, influenzerà anche altri nodi.

Come prevenire un singolo punto di errore?

Quindi qui la tolleranza ai guasti è migliore perché i messaggi possono viaggiare lungo un percorso diverso, evitando un singolo punto di errore.

Ma sicuramente, arriva con le sue complessità, come un collegamento di rete può essere più veloce di altri e alcuni messaggi possono superare altri e quindi portare a incoerenze di dati in un ambiente simultaneo. Possiamo usare i vettori di versione per questi.

Il vettore di versione è un blog completamente diverso, quindi non discusso qui.

Questo potrebbe averti dato una discreta quantità di architettura multi-leader, quindi pensi che ne valga la pena? O dovremmo evitare il multileader?

Potete seguirmi e iscrivervi per rimanere aggiornati con me :)

Progettazione di applicazioni a uso intensivo di dati: le grandi idee alla base di sistemi affidabili, scalabili e gestibili: di Martin Kleppmann