Perché il problema del consenso è così importante nel calcolo distribuito?

19

Nel calcolo distribuito, il problema del consenso sembra essere uno degli argomenti centrali che ha attratto un'intensa ricerca. In particolare, l'articolo "Impossibilità di un consenso distribuito con un processo difettoso" ha ricevuto il PODC Influential Paper Award 2001 .

Quindi perché il problema del consenso è così importante? Cosa possiamo ottenere con consenso sia in teoria che in pratica?

Eventuali riferimenti o esposizioni sarebbero davvero utili.

reference-request big-picture dc.distributed-comp

— Hengxin
fonte

18

Il documento che citi è importante per 2 motivi:

Mostra che non esiste un algoritmo di consenso deterministico asincrono che tolleri anche un singolo errore di crash. Si noti che nell'impostazione sincrona esiste un algoritmo deterministico che termina con round quando i processi bloccano. $f+1$ $\le f$
Introduce la bivalenza e l' univalenza delle configurazioni (*), che verranno utilizzate in seguito in molti limiti inferiori e prove di impossibilità.

applicazioni

Un'importante applicazione del problema del consenso è l'elezione di un coordinatore o leader in un ambiente a tolleranza d'errore per l'avvio di un'azione globale. Un algoritmo di consenso ti consente di farlo al volo, senza fissare in anticipo un "supernodo" (che introdurrebbe un singolo punto di errore).

Un'altra applicazione mantiene la coerenza in una rete distribuita: supponiamo di avere nodi di sensori diversi che monitorano lo stesso ambiente. Nel caso in cui alcuni di questi nodi del sensore si arrestino in modo anomalo (o addirittura inizino a inviare dati danneggiati a causa di un errore hardware), un protocollo di consenso garantisce la solidità contro tali guasti.

(*) Una serie di algoritmi distribuiti è una sequenza di configurazioni. Una configurazione è un vettore degli stati locali dei processi. Ogni processo esegue una macchina a stati deterministici. Qualsiasi algoritmo di consenso corretto deve infine raggiungere una configurazione in cui ogni processo ha deciso (irrevocabilmente) lo stesso valore di input. Una configurazione è - valida se, indipendentemente da ciò che fa l'avversario, tutte le possibili estensioni di portano a un valore decisionale di . Analogamente, possiamo definire - valenza . Una configurazione è bivalente se entrambe le decisioni sono raggiungibili da $C$ $1$ $C$ $1$ $0$ $C$ $C$ (quale dei due è raggiunto dipende dall'avversario). Chiaramente, nessun processo può essere deciso in una configurazione bivalente , poiché altrimenti otteniamo una contraddizione nell'accordo! Quindi, se siamo in grado di costruire una sequenza infinita di tali configurazioni bivalenti, abbiamo dimostrato che non esiste un algoritmo di consenso in questa impostazione. $C$

— Peter
fonte

2

@AJed Come supplemento: ho dato un'occhiata alla sincronizzazione della carta di Maurice Herlihy e ora posso presentare ulteriori importanti implicazioni teoriche del problema del consenso. Utilizzando l'idea del numero di consenso , si può dimostrare che esiste una gerarchia infinita di primitive di sincronizzazione, in modo tale che nessuna primitiva a un livello possa essere utilizzata per un'implementazione senza attesa di qualsiasi primitiva a livelli superiori. In parole povere, il problema del consenso si presenta come una teoria unificata sulla definizione del potere relativo delle operazioni di sincronizzazione primitive. È elegante.

— hengxin,

1

Ho qualche difficoltà a comprendere la prova del risultato di impossibilità FLP. Potresti darmi qualche suggerimento? Fare riferimento a [Prova FLP] ( stackoverflow.com/q/15131730/1833118 ). Grazie.

— hengxin,

"dove ogni processo ha deciso" forse dovrebbe essere "dove ogni processo corretto ha deciso"?

— nbro,

Dovresti spiegare chi è l'avversario in "qualunque cosa faccia l'avversario".

— nbro,

"tutte le possibili estensioni di C", cosa intendi con "estensione di C"? Cos'è un'estensione di una configurazione, in generale?

— nbro,

7

Mostra che non esistono algoritmi deterministici tolleranti ai guasti. Un risultato teorico piuttosto forte, che costringe i progettisti a gestire diversamente la tolleranza agli errori, alcuni dei quali sono la sincronizzazione e la randomizzazione.

Commento: a mio avviso, la sincronizzazione è un presupposto aggiuntivo del sistema che difficilmente si trova nelle applicazioni pratiche.

Per riferimenti, controlla il link Wikipedia . Controlla anche questo blog per applicazioni pratiche

— AJed
fonte

1

Sì, preferisco la randomizzazione alla sincronizzazione. L'ambiente in cui gioca il calcolo distribuito è molto scarso nel senso di asincronizzazione, ritardo illimitato, fallimento imprevisto e troppo non deterministico. Finché non è perfetto, perché non usiamo la randomizzazione, ottenendo alcune garanzie evitando troppa complessità.

— hengxin,

1

A proposito di sincronizzazione, in teoria non mi piace il presupposto . Tuttavia, nell'industria , la sincronizzazione o la sincronizzazione parziale viene applicata frequentemente. Ad esempio, Google Spanner è un database replicato in modo sincrono distribuito a livello globale . Mi rende meno decisivo. Qual è la tua opinione?

— hengxin,

Immagino sia meglio vedere come viene implementata la sincronizzazione lì. Ma è un riferimento molto interessante. - ciò che intendo, non è una caratteristica naturale del sistema. Deve essere aggiunto ad esso.

— AJed

In generale, non si dovrebbe dare come riferimento Wikipedia. Ho appena letto l'articolo di Wikipedia: è abbastanza incompleto e non organizzato; potrebbe anche essere fonte di confusione.

— nbro,

5

Una delle ragioni per cui i problemi di consenso sono importanti è che sono molto semplici e sono una specie di problemi universali per i sistemi di elaborazione distribuiti.

Se riusciamo a risolvere il consenso in un sistema distribuito asincrono, possiamo usarlo per linearizzare le azioni su oggetti condivisi e ottenere linearità per oggetti condivisi.

Per semplicità, quanti problemi riesci a pensare quali sono più semplici che concordare un valore?

Il risultato dell'impossibilità riguardo al consenso nei sistemi (puri) distribuiti asincroni ci dice che non possiamo risolvere i problemi che vogliamo risolvere nei sistemi (puri) asincroni distribuiti senza alcune "cose" aggiuntive. Questo porta a modelli asincroni in cui possiamo risolvere il consenso, ad esempio algoritmi randomizzati, rilevatori di guasti, modelli di sincronia parziale, ecc.

Questo è anche il motivo per cui in pratica gli algoritmi che risolvono il consenso come Paxos di Lamport, Chubby di Google, Apache ZooKeeper e più recentemente Raft sono al centro dei sistemi distribuiti in cui spesso vogliamo replicare uno stato tra i server.

— Kaveh
fonte

0

Vorrei solo aggiungere che la natura del calcolo sta diventando sempre più distribuita nello stack: molte CPU, molti processi su una macchina, molte macchine connesse tramite LAN, molte LAN collegate tramite Internet.

Questo rende fondamentale il problema dello stato comune (distribuito / globale): ogni algoritmo assume un certo stato e se il calcolo deve essere eseguito in più di un posto, anche lo stato deve essere distribuito.

Articoli influenti ( Paxos , e più recentemente Raft ) in questo dominio sono stati pubblicati dopo il documento che stai citando. Entrambi affrontano le questioni del consenso in presenza di alcuni fallimenti.

Gli errori bizantini possono essere evitati nei sistemi distribuiti usando pochi approcci.

Dai un'occhiata alla voce di Wikipedia sulla tolleranza ai guasti bizantina .

— diginoise
fonte

Il risultato di impossibilità di FLP si applica anche nell'impostazione del fallimento di base (crash), quindi non sono sicuro di quale sia il punto del paragrafo sull'evitare i fallimenti bizantini. Si noti che se non si verificano errori, il consenso è piuttosto semplice: un processo fisso trasmette il suo valore e ogni processo decide tale valore non appena viene ricevuto.

— Kaveh,