Come gestire correttamente la replica di database asincrona?

Question

Sto considerando l'utilizzo di Amazon RDS con read replicas per ridimensionare il nostro database.

Alcuni dei nostri controller nella nostra applicazione Web sono di lettura/scrittura, alcuni di loro sono di sola lettura. Abbiamo già un modo automatico per identificare quali controllori sono di sola lettura, quindi il mio primo approccio sarebbe stato quello di aprire una connessione al master quando si richiede un controller di lettura/scrittura, altrimenti aprire una connessione a una replica di lettura quando si richiede una lettura solo controller.

In teoria, suona bene. Ma poi mi sono imbattuto nel concetto di ritardo di replica , che in pratica dice che una replica può trovarsi a diversi secondi dietro al master.

Immaginiamo il seguente caso d'uso, allora:

• I messaggi del browser per /create-account, che viene letto/scrittura, collegando in tal modo al master
• creato l'account, transazioni impegnato, e il browser ottiene reindirizzato a /member-area
• Il browser si apre /member-area, che è di sola lettura, quindi si collega a una replica. Se la replica è anche leggermente indietro rispetto al master, l'account utente potrebbe non esistere ancora sulla replica, causando di conseguenza un errore.

Come si utilizzano realisticamente le repliche di lettura nell'applicazione, per evitare questi potenziali problemi?

Answer 1

Questo è un problema difficile e ci sono molte potenziali soluzioni. Una possibile soluzione è quella di guardare a ciò che facebook did,

TLDR - leggere le richieste GET indirizzato al leggere copia unica, ma se si fa una scrittura, poi per i prossimi 20 secondi, tutta la tua legge andare al master scrivibile .

L'altro problema principale che abbiamo dovuto affrontare era che solo i nostri master database in California potevano accettare operazioni di scrittura. Questo fatto significava di cui avevamo bisogno per evitare di servire pagine che facevano le scritture di database da Virginia perché ognuna avrebbe dovuto attraversare il paese ai nostri database master in California. Fortunatamente, le nostre pagine di accesso più frequenti (pagina iniziale, profili, pagine di foto) più frequenti di non eseguono alcuna scrittura in condizioni normali. Il problema si riduce così, quando un utente effettua una richiesta per una pagina, come decidiamo se è "sicuro" per inviare in Virginia o se deve essere instradato in California?

Questa domanda si è rivelata avere una risposta relativamente semplice. Uno dei primi server che una richiesta utente ha inviato a Facebook viene chiamato bilanciamento del carico ; La principale responsabilità di questa macchina è quella di selezionare un server Web per gestire la richiesta, ma serve anche una serie di altri scopi : protezione dagli attacchi di tipo Denial of Service e connessioni utente multiplexing per nominarne alcuni. Questo bilanciatore di carico ha la capacità di essere eseguito in modalità Livello 7 in cui è possibile esaminare l'URI a un utente che richiede e prende decisioni di routing in base a tali informazioni .Questa funzione ha significato che è stato semplice impostare il bilanciamento del carico sulle nostre pagine "sicure" e potrebbe decidere se inviare la richiesta in Virginia o California in base al nome della pagina e alla posizione dell'utente.

C'è tuttavia un'altra ruga in questo problema. Diciamo che vai a editprofile.php per cambiare la tua città natale. Questa pagina non è contrassegnata come sicura quindi viene indirizzata verso la California e tu apporti la modifica. Quindi vai su per visualizzare il tuo profilo e, poiché si tratta di una pagina sicura, ti inviamo a Virginia. A causa del ritardo di replicazione menzionato in precedenza, , tuttavia, potresti non vedere la modifica appena apportata! Questa esperienza è molto confusa per un utente e porta anche al doppio post. Abbiamo ottenuto intorno a questa preoccupazione impostando un cookie nel tuo browser con l'ora corrente ogni volta che scrivi qualcosa nei nostri database. Il bilanciamento del carico cerca anche quel cookie e, se nota che hai scritto qualcosa di entro 20 secondi, ti invierà incondizionatamente a California. Poi, quando sono passati 20 secondi e siamo certi che i dati di sono stati replicati in Virginia, ti consentiremo di tornare indietro per le pagine di sicurezza .

Answer 2

Ho lavorato con l'applicazione che utilizzava pseudo- vertical partitioning. Poiché solo una manciata di dati era sensibile al fattore tempo, l'applicazione veniva solitamente recuperata dagli slave e dal master solo in casi selezionati.

Come esempio: quando l'utente ha aggiornato la propria password, chiede sempre master per la richiesta di autenticazione. Quando si cambiano i dati non sensibili al tempo (come Preferenze utente), verrà visualizzata la finestra di dialogo del successo insieme alle informazioni che potrebbe richiedere un po 'di tempo prima che tutto venga aggiornato.

Alcune altre idee che potrebbe o non potrebbe funzionare a seconda dell'ambiente:

• Dopo l'aggiornamento entità di calcolo del checksum, memorizzarlo nella cache dell'applicazione e durante il recupero dei dati sempre chiedere il rispetto di checksum
• Utilizzo del browser negozio/biscotto per la memorizzazione di delta garantire l'utente vede sempre l'ultima versione
• Aggiungi "up-to-date" di bandiera e invalidare in modo sincrono su ogni nodo slave prima/dopo l'aggiornamento

Qualunque soluzione tu scelga, ricorda che è soggetto a CAP Theorem.