Teorema 1. Es imposible en el modelo asíncrono de red para implementar un objeto de datos lectura/escritura que garantice las siguientes propiedades:
• Disponibilidad
• Consistencia atómica en todas las ejecuciones aceptables (incluyendo aquellas en las que los mensajes están perdidos).
Lo dicho, hablemos sobre las particiones, como "mensajes perdidos...en el modelo de red asíncrono" es directamente análogo.
Echemos un vistazo a un ejemplo:
En el diagrama anterior, la red está particionada. Las mitades izquierda y derecha (quizá éstas correspondan a dos continentes) no se pueden comunicar del todo. Cuatro clientes y cuatro nodos de servidor de datos son mostrados en el diagrama. Así que ¿cuáles son nuestras opciones?
1. Denegar todas las escrituras. Si denegamos todas las escrituras entonces la red está particionada, podemos aún escribir datos completamente consistentes en ambos lados. Así que ésta es una opción. Obtenemos disponibilidad para escribir, y consistencia sostenida.
2. Permitir escrituras en un lado. Mediante algún tipo de mecanismo de consenso, podríamos dejar que un lado de la partición "gane" y tener un maestro (mostrado en el diagrama con "M"). En este caso, las lecturas y escrituras podrían ocurrir en ese lado. En otras particiones no-maestras, podríamos tanto (a) ser estrictos y no permitir operaciones, o (b) permitir lecturas eventualmente consistentes, pero no escrituras. Así, en esta situación tenemos consistencia completa en una partición, y operación parcial en el resto.
3. Permitir lecturas y escrituras en todas las particiones. Aquí, mantenemos disponibilidad, pero debemos sacrificar consistencia fuerte. Una partición no verá las operaciones y el estado de la otra hasta que la red sea restaurada. Una vez restaurada, necesitaremos un método para fusionar las operaciones que ocurrieron mientras estaba desconectado.
Una técnica de mitigación también viene a la mente. Supón que un cliente particular C tenga mucha más probabilidad de necesitar una entidad X que otros clientes. Si almacenamos la copia maestra de X en un servidor dedicado a C, incrementamos la probabilidad de que C pueda leer y escribir X en la anterior opción (2). Llamemos a ésto "buscador inteligente". Un ejemplo del mundo real de ésto podría ser "almacenar copias maestras de datos para los usuarios de la costa este en la costa este". La búsqueda inteligente no soluciona nuestros problemas, pero podría probablemente reducir su frecuencia.
Afortunadamente lo anterior es una buena "prueba" informal de CAP. Es realmente bastante simple.
Particiones de red triviales
Muchas particiones de red comunes son lo que nosotros podemos denominar triviales. Considerémoslo desde la perspectiva de la anterior opción (2). Definimos que una partición de red trivial es una tal que en todas las particiones no-maestras, no hay
* clientes vivos en todos, o
* servidores en todos
Por ejemplo si tenemos muchos centros de datos y nuestros clientes son navegadores web de Internet, y uno de nuestros centros de datos se hace completamente oscuro (y nos quedan más), es una partición de red trivial (asumimos aquí que podemos fallar sobre el estado maestro en tal situación). Asimimismo, perder un estante simple en su integridad es a menudo una partición de red trivial.
En estas situaciones, puede aún ser consistente y disponible. (Bien, para los clientes particionados, estamos no disponibles, pero por supuesto es una certeza si no puede alcanzar ningún servidor en ningún sitio)
Fuente: http://blog.mongodb.org/post/505822180/on-distributed-consistency-part-3-network
