Diseño de aplicaciones con uso intensivo de datos, 2nd Edición
by Martin Kleppmann, Chris Riccomini
capítulo 10. Consistencia y consenso
Un antiguo adagio advierte: “Nunca vayas a la mar con dos cronómetros; lleva uno o tres”.
Frederick P. Brooks Jr., El mítico mes-hombre: Ensayos sobre ingeniería de software (1995)
Muchas cosas pueden salir mal en los sistemas distribuidos, como se explica en Capítulo 9. Si queremos que un servicio siga funcionando correctamente a pesar de que esas cosas salgan mal, necesitamos encontrar formas de tolerar los fallos.
Una de las mejores herramientas que tenemos para la tolerancia a fallos es la replicación. Sin embargo, como vimos en Capítulo 6, tener múltiples copias de los datos en múltiples réplicas aumenta el riesgo de inconsistencias. Las lecturas pueden ser gestionadas por una réplica que no esté actualizada, lo que da lugar a resultados obsoletos. Si varias réplicas pueden aceptar escrituras, tenemos que lidiar con posibles conflictos entre valores que se escribieron simultáneamente en diferentes réplicas. A alto nivel, tenemos dos filosofías contrapuestas para abordar estas cuestiones:
- Consistencia eventual
-
En esta filosofía, el hecho de que un sistema esté replicado se hace visible para la aplicación, y se espera que tú, como desarrollador de la aplicación, te ocupes de las inconsistencias y los conflictos que puedan surgir. Este enfoque se utiliza a menudo en sistemas con replicación multilíder (consulta “Replicación con múltiples líderes”) y sin líder (consulta “Replicación sin líder”).
- Consistencia fuerte
-
Esta filosofía sostiene ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access