2015-04-01 10 views
29

Mi sono imbattuto nel concetto di "Strong Eventual Consistency". Si suppone che sia più forte di "Event Consistency" ma più debole di "Strong Consistency"? Qualcuno potrebbe spiegare le differenze tra questi tre concetti con esempi applicabili?"Eventuale coerenza" rispetto a "Strong Event Coerance" vs "Strong Consistency"?

http://en.wikipedia.org/wiki/Eventual_consistency#Strong_Eventual_Consistency http://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

Molte grazie.

risposta

86

DISCLAIMER: Il seguente testo dovrebbe darvi un'idea approssimativa delle differenze tra coerenza finale, forte coerenza finale e forte coerenza. Ma sono in qualche modo una semplificazione eccessiva. Così li prendere con un grano di sale;)


Per prima cosa: quando si parla di coerenza ci riferiamo ad uno scenario in cui le diverse entità (nodi) hanno la loro copia di un oggetto di dati. Ora, i conflitti sorgono perché ogni nodo può aggiornare la propria copia (ad esempio perché ci sono client, ognuno connesso a qualche nodo, chiedendo loro di farlo), quindi se leggo i dati da diversi nodi vedrò valori diversi. È qui che entrano in gioco la coerenza finale (CE), la consistenza finale forte (SEC) e la forte coerenza (SC).

Coerenza Eventuale conflitti possono sorgere, ma i nodi di comunicare l'un l'altro i loro cambiamenti per risolvere i conflitti, così nel tempo sono d'accordo sul valore definitivo. Pertanto, se non vengono apportate ulteriori modifiche ai dati per un determinato periodo, tutti i nodi saranno d'accordo nel valore dei dati (vale a dire saranno eventualmente d'accordo) in modo che i lettori di dati alla fine vedano lo stesso valore.

Esempio: due nodi A e B (nA e nB) presentano ognuno una copia di una stringa, che è l'aggiornamento con operazioni read() e write(string). Diciamo che ognuno ha il proprio cliente (cliA e cliB). Diciamo che inizialmente entrambi i nodi memorizzano lo stesso valore "Joe", ma ad un certo momento nA lo aggiorna su "Frank" (chiamate write("Frank")). Quindi nA indicherà nB che il valore è stato aggiornato; poiché entrambi i valori differiscono, è emerso un conflitto ma può essere risolto utilizzando alcuni criteri (ad esempio, le vincite dell'ultimo scrivo), quindi nB aggiorna infine il suo record anche a "Frank". Prima che il conflitto venga risolto cliA e cliB verranno visualizzate versioni diverse dei dati (il risultato operativo read() sarà diverso), ma alla fine entrambi riveleranno lo stesso valore.

Ricordare che se entrambi i nodi aggiornano il loro valore contemporaneamente, la risoluzione dei conflitti è ancora possibile ma più complicata. Questo è dove splende SEC.

Strong Event Coerance Questo è un caso speciale di EC, valido solo per determinati tipi di dati.

Supponiamo che l'oggetto dati condiviso sia un contatore e che gli aggiornamenti vengano effettuati tramite le operazioni add(int value) e substract(int value). In questo caso, l'ordine in cui applichiamo gli aggiornamenti non è importante!Quindi, se entrambi nA e nB inizio con un controvalore pari a 0, e se poi nA corre add(10) e nB piste substract(5) (simultaneosly), hanno solo bisogno di inviare l'operazione di aggiornamento tra loro senza preoccuparsi per la risoluzione dei conflitti , alla fine si assicura che raggiungeranno lo stesso valore (ricordate che, al contrario, nell'esempio precedente per la CE potrebbe essere necessaria una risoluzione dei conflitti)!

Purtroppo SEC è applicabile solo in alcuni tipi di dati e operazioni che hanno proprietà specifiche (commutatività e altri). Tali tipi di dati sono indicati con Tipo di dati replicati senza conflitti (CRDT).

consistenza consistente Molto diverso dagli altri due. Qui è necessario che, in seguito all'aggiornamento, tutti i nodi concordino sul nuovo valore prima di rendere visibile il nuovo valore ai client. In questo modo gli aggiornamenti sono visibili a tutti i client allo stesso tempo, quindi leggeranno sempre lo stesso valore. Ora questo introduce il requisito per alcuni blocchi nelle operazioni di aggiornamento. Sia in EC che in SEC, un'operazione di aggiornamento è stata terminata non appena è stata aggiornata la copia locale (quindi l'operazione è stata trasmessa agli altri nodi). Qui un aggiornamento del client non viene restituito finché tutti i nodi non hanno concordato il valore dei dati e, mentre ciò viene fatto, tutti gli accessi a qualsiasi copia di tali dati sono "bloccati" (quindi le altre letture dei client sono bloccate). Nel nostro esempio per la CE, se verranno bloccati CLIA corre write("Frank"), CLIA fino a quando l'aggiornamento viene concordata da entrambi nA e nB, e allora sarà reso visibile per entrambi CLIA e CLIB a allo stesso tempo, ovvero l'operazione read() dovrebbe restituire lo stesso valore da quel momento in poi.

+1

Ben spiegato, grazie! – njzhxf

+0

Una descrizione molto bella, bellissima! –

+4

Per chiarire, la coerenza forte richiede solo che tutti i nodi concordino sul valore corrente. Non è un requisito che il blocco dei nodi venga letto mentre si verifica una scrittura, possono invece causare il ritardo della scrittura. Fondamentalmente, la scrittura sarà in sospeso, fino a quando tutti i nodi non saranno in grado di utilizzare il nuovo valore in modo coerente. – AffluentOwl

Problemi correlati