Amazon popularizó el concepto de "Consistencia eventual". Su definición es:
el sistema de almacenamiento garantiza que si no se realizan nuevas actualizaciones al objeto, eventualmente todos los accesos retornarán el último valor actualizado
Esto no es nuevo, pero es grande tener el concepto formalizado/popularizado: Unos pocos ejemplos de sistemas eventualmente consistentes:
1. DNS
2. Replicación asíncrona maestro/esclavo en un RDBMS (también en MongoDB)
3. memcached en frente de mysql, cacheando lecturas
Muchos (no todos) ejemplos tradicionales que vienen a la mente tienen lecturas eventualmente consistentes, excepto un escritor simple (por "escritor simple" entendemos un servidor de datos, no los clientes). Las cosas se consiguen más interesantes - y complejas - cuando hay muchos escritores. Amazon Dynamo es un ejemplo de sistema de "muchos escritores eventualmente consistentes". Todo lo anterior sea quizás "escritor simple eventualmente consistente".
Cabe destacar otra tecnología tracional que son las colas de mensajes. Estas tienen propiedades reminiscentes de consistencia eventual.
Formas de consistencia
Tomemos un vistazo a un ejemplo particular. Considera un sistema usando MongoDB en la siguiente configuración:
“master” (maestro), “slave” (esclavo), y “slave” podrían ser instancias mongo por ejemplo - u otras bases de datos con replicación asíncrona. Los clientes leen aleatoriamente de cualquier esclavo para una consulta dada, y siempre escribe en el maestro. Dos esclavos y dos clientes son mostrados, pero se asume que cada uno de ellos escalan horizontalmente (scale out)
Este tipo de sistema es lo que calificamos como "escritor simple de consistencia eventual". Así que ¿cuáles son sus propiedades? (1) Un cliente puede leer datos antiguos. (2) El cliente podría ver operaciones de escritura fuera de servicio.
Supongamos que estamos almacenando alguna entidad x en el repositorio. Asumimos que las entidades tienen un valor inicial de cero. Hay una serie de escrituras a x por clientes:
W(x=3), W(x=7), W(x=5)
Debido a que el sistema es eventualmente consistente, si las escrituras a x se detienen en algún punto, sabemos que leeremos eventualmente 5 — que es, R(x==5). Sin embargo a corto plazo un cliente podría por ejemplo ver:
R(x==7), R(x==0), R(x==5), R(x==3)
(Nota: más nodos que 2 esclavos son necesarios para este ejemplo de comportamiento)
Así que es nuestra forma más débil - eventualmente consistente con lecturas fuera de servicio a corto plazo.
Podemos hacer ésto más fuerte. considera la configuración mongodb SourceForge (diagrama grande aquí). Esta configuración es eventualmente consistente, pero no veremos el resultado de las escrituras fuera de servicio. Esto provee consistencia de lectura monotónica.
Una posible propiedad de consistencia eventual es la consistencia lee-tus-propias-escrituras, lo que significa que un proceso está garantizado para ver que las escrituras se han hecho cuando se han leído. Esta es una propiedad muy útil que hace la programación más fácil. Nótese que ninguno de los ejemplos de arriba proveen consistencia lee-tus-propias-escrituras. También el valor a considerar con este modelo es la definición de "tu". En una aplicación web, que puede ser el usuario. Si el balanceador de carga del sistema envía peticiones a diferentes servidores de aplicaciones, tener consistencia lee-tu-propia-escritura para un servidor de aplicaciones simple no soluciona la necesidad de consistencia en el mundo real.
Caso de uso checklist EC
Así que cuando se usa consistencia eventual, es bueno para la arquitectura preguntarse:
* ¿mi caso de uso puede tolerar lecturas antiguas?
* ¿puede tolerar lectura de valores fuera de servicio? si no, ¿es mi configuración de lectura monotónica consistente?
* ¿puede tolerar no leer mis propias escrituras? si no, ¿es mi configuración lee-tu-propia-escritura consistente?
Fuente: http://blog.mongodb.org/post/498145601/on-distributed-consistency-part-2-some-eventual
