Consistencia eventual

La consistencia eventual es un modelo de consistencia utilizado en computación distribuida para lograr alta disponibilidad . Un sistema con consistencia eventual asegura que si no se realizan nuevas actualizaciones a un elemento de datos dado, eventualmente todos los accesos de lectura a ese elemento devolverán el último valor actualizado. ^{[ 1 ]} La consistencia eventual, también llamada replicación optimista , ^{[ 2 ]} se implementa ampliamente en sistemas distribuidos y tiene sus orígenes en los primeros proyectos de computación móvil. ^{[ 3 ]} Se dice que un sistema que ha logrado la consistencia eventual ha convergido o ha logrado la convergencia de réplicas . ^{[ 4 ]} La consistencia eventual es una garantía débil: la mayoría de los modelos más fuertes, como la linealizabilidad , son trivialmente consistentes eventualmente.

Los servicios de consistencia eventual suelen clasificarse como proveedores de semántica BASE (disponibilidad básica, estado flexible, consistencia eventual), en contraste con la ACID tradicional (atomicidad, consistencia, aislamiento, durabilidad). Las definiciones aproximadas de cada término en BASE son: ^{[ 5 ] [ 6 ]}

• Disponibilidad básica : se refiere a la accesibilidad concurrente de la base de datos por parte de los usuarios en todo momento. Un usuario no necesita esperar a que otros finalicen la transacción antes de actualizar el registro. ^{[ 7 ]}
• Estado blando : se refiere a la noción de que los datos pueden tener estados transitorios o temporales que pueden cambiar con el tiempo, incluso sin desencadenantes o entradas externas. Por lo tanto, incluso sin actualizaciones externas adicionales, hasta que una actualización converja, es posible que diferentes consultas para un registro vean valores diferentes. ^{[ 7 ]}
• Consistencia eventual : esto significa que el registro alcanzará la consistencia cuando se hayan completado todas las actualizaciones concurrentes. En ese momento, las aplicaciones que consulten el registro verán el mismo valor. ^{[ 7 ]}

La consistencia eventual ha sido objeto de críticas ^{[ 8 ]} por añadir complejidad a las aplicaciones de software distribuidas. Esta complejidad surge porque la consistencia eventual solo proporciona una garantía de vivacidad (asegurando que las lecturas finalmente devuelvan el mismo valor) sin garantías de seguridad , permitiendo cualquier valor intermedio antes de la convergencia. Los desarrolladores de aplicaciones encuentran esto un desafío porque difiere de la programación de un solo hilo, donde las variables devuelven de forma fiable sus valores asignados inmediatamente. Con garantías de consistencia débiles, los desarrolladores deben considerar cuidadosamente estas limitaciones, ya que las suposiciones incorrectas sobre los niveles de consistencia pueden conducir a errores sutiles que solo se manifiestan durante fallos de red o alta concurrencia. ^{[ 9 ]}

Para garantizar la convergencia de réplicas, un sistema debe conciliar las diferencias entre múltiples copias de datos distribuidos. Esto consta de dos partes:

• intercambio de versiones o actualizaciones de datos entre servidores (a menudo conocido como anti-entropía ); ^{[ 10 ]} y
• elegir un estado final apropiado cuando se han producido actualizaciones simultáneas, lo que se denomina reconciliación .

El enfoque más apropiado para la reconciliación depende de la aplicación. Un enfoque común es "el último escritor gana". ^{[ 1 ]} Otro es invocar un gestor de conflictos especificado por el usuario. ^{[ 4 ]} A menudo se utilizan marcas de tiempo y relojes vectoriales para detectar la concurrencia entre actualizaciones. Algunas personas utilizan "el primer escritor gana" en situaciones donde "el último escritor gana" es inaceptable. ^{[ 11 ]}

La conciliación de escrituras concurrentes debe ocurrir en algún momento antes de la siguiente lectura, y puede programarse en diferentes instantes: ^{[ 3 ] [ 12 ]}

• Corrección de lectura: La corrección se realiza cuando una lectura encuentra una inconsistencia. Esto ralentiza la operación de lectura.
• Reparación de escritura: La corrección se realiza durante una operación de escritura, lo que ralentiza dicha operación.
• Reparación asíncrona: La corrección no forma parte de una operación de lectura o escritura.

Mientras que la consistencia eventual solo garantiza la vivacidad (las actualizaciones se observarán eventualmente), la consistencia eventual fuerte (SEC) añade la garantía de seguridad de que dos nodos cualesquiera que hayan recibido el mismo conjunto (no ordenado) de actualizaciones estarán en el mismo estado. Un enfoque común para garantizar la SEC son los tipos de datos replicados sin conflictos . ^{[ 13 ]}

• Teorema CAP

• Burckhardt, Sebastian (09-10-2014). "Principios de consistencia eventual" . Fundamentos y tendencias en lenguajes de programación . 1 ( 1–2 ): 1–150 . doi : 10.1561/2500000011 . ISSN 2325-1107 .