Esempio di mondo reale di Paxos

Question

Qualcuno può darmi un esempio reale di come l'algoritmo di Paxos viene utilizzato in un database distribuito? Ho letto molti articoli su Paxos che spiegano l'algoritmo, ma nessuno di loro spiega realmente con un esempio reale.

Un semplice esempio potrebbe essere un'applicazione bancaria in cui un account viene modificato tramite più sessioni (vale a dire un deposito presso un cassiere, un'operazione di addebito ecc.). Paxos è solito decidere quale operazione si verifica prima? Inoltre, cosa si intende per più istanze del protocollo Paxos? Come viene usato questo? Fondamentalmente, sto cercando di capire tutto questo attraverso un esempio concreto piuttosto che termini astratti.

Answer 1

Ad esempio, abbiamo il sistema MapReduce in cui il master è composto da 3 host. Uno è padrone e gli altri sono schiavi. La procedura di scelta del master utilizza l'algoritmo di Paxos.

anche Chubby di Google Big Table utilizza Paxos: The Chubby Lock Service for Loosely-Coupled Distributed Systems, Bigtable: A Distributed Storage System for Structured Data

Answer 2

Il database Clustrix è un database distribuito che utilizza Paxos nel gestore delle transazioni. Paxos viene utilizzato dagli interni del database per coordinare i messaggi e mantenere l'atomicità della transazione in un sistema distribuito.

• Il coordinatore è il nodo della transazione ha avuto origine sulla
• I partecipanti sono i nodi che hanno modificato il database per conto di
• transazione I lettori sono i nodi che ha eseguito il codice per conto della transazione , ma non ha modificato qualsiasi stato
• Gli Acceptor sono i nodi che registrano lo stato della transazione.

le seguenti operazioni vengono prese durante l'esecuzione di una sincronizzazione di transazione:

1. coordinatore invia un messaggio prepararsi a ogni partecipante.
2. I partecipanti bloccano lo stato della transazione. Mandano i messaggi PREPARATI al coordinatore.
3. Il coordinatore invia i messaggi ACCEPT agli Acceptor.
4. Gli Accettatori registrano l'ID di appartenenza, la transazione, l'ID di commit e i partecipanti. Invia messaggi ACCEPTED al coordinatore.
5. Coordinatore comunica all'utente il commit riuscito.
6. Il coordinatore invia messaggi COMMIT a ciascun partecipante e lettore.
7. I partecipanti e i lettori eseguono il commit della transazione e aggiornano di conseguenza lo stato della transazione. Invia messaggi COMMITTATI al coordinatore.
8. Il coordinatore rimuove lo stato interno e ora viene completato.

Questo è tutto trasparente per l'applicazione ed è implementato negli interni del database. Pertanto, per la tua applicazione bancaria, tutto il livello di applicazione necessario è eseguire la gestione delle eccezioni per i conflitti di deadlock. L'altra chiave per implementare un database su scala è la concorrenza, che è generalmente supportata da MVCC (controllo della concorrenza a più versioni).