Modelo de consistencia utilizado en computación distribuida para lograr alta disponibilidad
La consistencia eventual es un modelo de consistencia utilizado en computación distribuida para lograr una alta disponibilidad que garantiza informalmente que, si no se realizan nuevas actualizaciones a un elemento de datos dado, eventualmente todos los accesos 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 orígenes en los primeros proyectos de computación móvil. [3] A menudo 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 eventualmente consistentes a menudo se clasifican como proveedores de semántica BASE (básicamente disponible, estado blando, consistencia eventual), en contraste con la tradicional ACID (atomicidad, consistencia, aislamiento, durabilidad) . [5] [6] En química, una base es lo opuesto a un ácido, lo que ayuda a recordar el acrónimo. [7] Según el mismo recurso, estas son las definiciones aproximadas de cada término en BASE:
- Básicamente disponible : las operaciones de lectura y escritura están disponibles tanto como sea posible (usando todos los nodos de un clúster de base de datos), pero podrían no ser consistentes (la escritura podría no persistir después de que se resuelvan los conflictos y la lectura podría no obtener la última escritura)
- Estado blando : sin garantías de consistencia, después de cierto tiempo, solo tenemos cierta probabilidad de conocer el estado, ya que es posible que aún no haya convergido.
- Consistencia eventual : si ejecutamos algunas escrituras y luego el sistema funciona durante el tiempo suficiente, podemos saber el estado de los datos; cualquier lectura posterior de ese elemento de datos devolverá el mismo valor.
La consistencia eventual es criticada a veces [8] por aumentar la complejidad de las aplicaciones de software distribuidas. Esto se debe en parte a que la consistencia eventual es puramente una garantía de vida (las lecturas eventualmente devuelven el mismo valor) y no garantiza la seguridad : un sistema eventualmente consistente puede devolver cualquier valor antes de converger.
Resolución de conflictos
Para garantizar la convergencia de réplicas, un sistema debe conciliar las diferencias entre varias copias de datos distribuidos. Esto consta de dos partes:
- intercambiar versiones o actualizaciones de datos entre servidores (a menudo conocido como antientropía ); [9] y
- elegir un estado final apropiado cuando se han producido actualizaciones simultáneas, denominada reconciliación .
El enfoque más adecuado para la conciliación depende de la aplicación. Un enfoque muy extendido es el de "el último escritor gana". [1] Otro es invocar un controlador de conflictos especificado por el usuario. [4] Las marcas de tiempo y los relojes vectoriales se utilizan a menudo para detectar la concurrencia entre actualizaciones. Algunas personas utilizan el "primer escritor gana" en situaciones en las que "el último escritor gana" es inaceptable. [10]
La conciliación de escrituras simultáneas debe ocurrir en algún momento antes de la siguiente lectura y puede programarse en diferentes instantes: [3] [11]
- Reparació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 lleva a cabo durante una operación de escritura, lo que ralentiza la operación de escritura.
- Reparación asincrónica: la corrección no es parte de una operación de lectura o escritura.
Fuerte consistencia eventual
Mientras que la consistencia eventual es solo una garantía de vida (las actualizaciones se observarán eventualmente), la consistencia eventual fuerte (SEC) agrega la garantía de seguridad de que dos nodos cualesquiera que hayan recibido el mismo conjunto (desordenado) de actualizaciones estarán en el mismo estado. Si, además, el sistema es monótono , la aplicación nunca sufrirá reversiones. Un enfoque común para garantizar la SEC son los tipos de datos replicados libres de conflictos . [12]
Véase también
Referencias
- ^ ab Vogels, W. (2009). "Eventualmente consistente". Comunicaciones de la ACM . 52 : 40–44. doi : 10.1145/1435417.1435432 .
- ^ Vogels, W. (2008). "Eventualmente consistente". Cola . 6 (6): 14–19. doi : 10.1145/1466443.1466448 .
- ^ ab Terry, DB; Theimer, MM; Petersen, K.; Demers, AJ; Spreitzer, MJ; Hauser, CH (1995). "Gestión de conflictos de actualización en Bayou, un sistema de almacenamiento replicado débilmente conectado". Actas del decimoquinto simposio de la ACM sobre principios de sistemas operativos - SOSP '95 . p. 172. CiteSeerX 10.1.1.12.7323 . doi :10.1145/224056.224070. ISBN 978-0897917155.S2CID 7834967 .
- ^ ab Petersen, K.; Spreitzer, MJ; Terry, DB; Theimer, MM; Demers, AJ (1997). "Propagación de actualización flexible para replicación débilmente consistente". ACM SIGOPS Operating Systems Review . 31 (5): 288. CiteSeerX 10.1.1.17.555 . doi :10.1145/269005.266711.
- ^ Pritchett, D. (2008). "Base: una alternativa ácida". Cola . 6 (3): 48–55. doi : 10.1145/1394127.1394128 .
- ^ Bailis, P.; Ghodsi, A. (2013). "Consistencia eventual hoy: limitaciones, extensiones y más allá". Cola . 11 (3): 20. doi : 10.1145/2460276.2462076 .
- ^ Roe, Charles (marzo de 2012). "ACID vs. BASE: El pH cambiante del procesamiento de transacciones de bases de datos". DATAVERSITY . DATAVERSITY Education, LLC . Consultado el 29 de agosto de 2019 .
- ^ H Yaniv Pessach (2013), Almacenamiento distribuido (Distributed Storage: Concepts, Algorithms, and Implementations ed.), Amazon, OL 25423189M,
Los sistemas que utilizan consistencia eventual dan como resultado una menor carga del sistema y una mayor disponibilidad del sistema, pero dan como resultado una mayor complejidad cognitiva para los usuarios y desarrolladores.
- ^ Demers, A.; Greene, D.; Hauser, C.; Irish, W.; Larson, J. (1987). "Algoritmos epidémicos para el mantenimiento de bases de datos replicadas". Actas del sexto simposio anual de la ACM sobre principios de computación distribuida - PODC '87 . p. 1. doi :10.1145/41840.41841. ISBN 978-0-89791-239-6.S2CID1889203 .
- ^ Rockford Lhotka. "Técnicas de concurrencia". Archivado el 11 de mayo de 2018 en Wayback Machine . 2003.
- ^ Olivier Mallassi (9 de junio de 2010). "Juguemos con Cassandra… (Parte 1/3)". OCTO Talks! . Consultado el 23 de marzo de 2011 .
Por supuesto, en un momento dado, hay muchas posibilidades de que cada nodo tenga su propia versión de los datos. La resolución de conflictos se realiza durante las solicitudes de lectura (lo que se denomina reparación de lectura) y la versión actual de Cassandra no proporciona un mecanismo de resolución de conflictos de Vector Clock (debería estar disponible en la versión 0.7). La resolución de conflictos se basa en la marca de tiempo (la que se establece cuando se inserta la fila o la columna): la marca de tiempo más alta gana y el nodo del que se están leyendo los datos es responsable de eso. Este es un punto importante porque la marca de tiempo la especifica el cliente en el momento en que se inserta la columna. Por lo tanto, todos los clientes de Cassandra deben estar sincronizados...
- ^ Shapiro, Marc; Preguiça, Nuno; Baquero, Carlos; Zawirski, Marek (10 de octubre de 2011). "Tipos de datos replicados sin conflictos". Actas de la 13.ª Conferencia internacional sobre estabilización, seguridad y protección de sistemas distribuidos de la SSS'11 . Springer-Verlag Berlín, Heidelberg: 386–400.
Lectura adicional
- Burckhardt, Sebastian (9 de octubre de 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.
