distributed-computing - parallel - distributed systems book

"Consistencia eventual" frente a "fuerte consistencia eventual" frente a "consistencia fuerte"?

Question

Me encontré con el concepto de "fuerte consistencia eventual". ¿Se supone que es más fuerte que "Consistencia eventual" pero más débil que "Consistencia fuerte"? ¿Podría alguien explicar las diferencias entre estos tres conceptos con ejemplos aplicables?

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

Muchas gracias.

Answer 1

DESCARGO DE RESPONSABILIDAD: El siguiente texto le dará una idea aproximada de las diferencias entre la consistencia eventual, la consistencia fuerte y la consistencia fuerte. Pero de alguna manera son una simplificación excesiva. Así que tómalo con un grano de sal;)

Lo primero es lo primero: cuando hablamos de coherencia nos referimos a un escenario en el que diferentes entidades (nodos) tienen su propia copia de algún objeto de datos. Ahora, surgen conflictos porque cada nodo puede actualizar su propia copia (por ejemplo, porque hay clientes, cada uno conectado a algún nodo, pidiéndoles que lo hagan), de modo que si leo los datos de diferentes nodos, veré valores diferentes. Aquí es donde entra en juego la consistencia eventual (EC), la fuerte consistencia eventual (SEC) y la consistencia fuerte (SC).

Eventual Coherencia Pueden surgir conflictos, pero los nodos se comunican mutuamente sus cambios para resolver esos conflictos, por lo que con el tiempo acuerdan el valor definitivo. Por lo tanto, si no se aplican más cambios a los datos durante un cierto período, todos los nodos estarán de acuerdo en el valor de los datos (es decir, finalmente estarán de acuerdo), de modo que los lectores de los datos finalmente verán el mismo valor.

Ejemplo: dos nodos A y B ( nA y nB ) tienen cada copia de una cadena, que se actualiza con las operaciones read() y write(string) . Digamos que cada uno tiene su propio cliente ( cliA y cliB ). Digamos que inicialmente ambos nodos almacenan el mismo valor "Joe", pero en algún momento nA lo actualiza a "Frank" (llamadas de write("Frank") ). Entonces nA le dirá a nB que el valor ha sido actualizado; como ambos valores difieren, un conflicto ha surgido pero se puede resolver usando alguna política (por ejemplo, last-write-wins), por lo que nB finalmente actualiza su registro también a "Frank". Antes de que se resuelva el conflicto, cliA y cliB verán diferentes versiones de los datos (el resultado de la operación de read() será diferente), pero eventualmente ambos verán el mismo valor nuevamente.

Tenga en cuenta que si ambos nodos actualizan su valor de manera simultánea, la resolución de conflictos aún es posible pero más complicada. Aquí es donde brilla la SEC.

Strong Eventual Consistency Este es un caso especial de EC, que es válido solo para ciertos tipos de datos.

Supongamos que el objeto de datos compartido es un contador, y las actualizaciones se realizan mediante operaciones de add(int value) y substract(int value) . En este caso, ¡ el orden en el que aplicamos las actualizaciones no importa ! Entonces si tanto nA como nB comienzan con un valor de contador de 0, y si entonces nA ejecuta add(10) y nB ejecuta substract(5) (simultáneamente), solo necesitan enviarse la operación de actualización sin importar la resolución del conflicto , eventualmente se asegura que alcanzarán el mismo valor (recuerde que, en contraste, en el ejemplo anterior para EC, podría requerirse alguna resolución de conflicto).

Lamentablemente, la SEC solo es aplicable en ciertos tipos de datos y operaciones que tienen propiedades específicas (conmutatividad y otros). Dichos tipos de datos se denominan tipos de datos duplicados sin conflictos (CRDT) .

Consistencia fuerte Muy diferente a los otros dos. Aquí es un requisito que en las operaciones de actualización todos los nodos acuerden el nuevo valor antes de hacer que el nuevo valor sea visible para los clientes. De esta forma, las actualizaciones son visibles para todos los clientes "al mismo tiempo", por lo que leerán el mismo valor en todo momento. Ahora esto introduce el requisito de cierto bloqueo en las operaciones de actualización. Tanto en EC como en SEC, una operación de actualización finalizó tan pronto como se actualizó la copia local (luego la operación se transmitió a los otros nodos). Aquí una actualización del cliente no regresa hasta que todos los nodos hayan acordado el valor de los datos, y mientras esto se hace, todos los accesos a cualquier copia de esos datos están ''bloqueados'' (para que las lecturas de otros clientes estén bloqueadas). En nuestro ejemplo para EC, si cliA ejecuta write("Frank") , cliA se bloqueará hasta que la actualización sea acordada por nA y nB , y luego se hará visible para cliA y cliB al mismo tiempo, es decir, la read() operación debería devolver el mismo valor a partir de ese momento.