Consenso y los límites del acuerdo
Entiende qué promete la replicación, qué resuelve el consenso y qué te obliga a elegir una partición de red.
AL TERMINAR, PODRÁS
- Distinguir replicación, consenso y consistencia
- Razonar sobre la disponibilidad de un quórum de mayoría
- Aplicar CAP solo bajo sus condiciones declaradas
Descripción del diagrama: Líder → A ✓; Líder → B ✓; Líder → C …; Líder → D …; Líder + A + B = 3/5: confirmada
Las copias necesitan una regla de orden
La replicación guarda datos en varios nodos para disponibilidad, durabilidad o capacidad de lectura.
Las copias por sí solas no deciden qué escrituras son las autoritativas cuando los mensajes se retrasan o fallan los líderes. Los protocolos de consenso coordinan el acuerdo sobre una secuencia de decisiones a pesar de fallas definidas. Raft usa elección de líder y replicación de un log para construir una máquina de estados replicada bajo un modelo de fallas por caída.
No hace automáticamente correcto el invariante de tu aplicación ni la protege frente a participantes maliciosos arbitrarios. La máquina de estados sigue necesitando transiciones deterministas y válidas, y una capa de almacenamiento implementada con cuidado.
Una mayoría tiene un costo
Un clúster de Raft de cinco miembros puede seguir avanzando con una mayoría de tres que se comunique, suponiendo que las condiciones de tiempo y disponibilidad del protocolo se cumplan en algún momento.
Perder tres miembros impide nuevas decisiones respaldadas por quórum. Los quórums se superponen, algo importante para conservar el historial confirmado cuando cambia el liderazgo, pero ahora la latencia incluye comunicación y registro duradero. Avisar que una escritura quedó guardada antes del punto de replicación requerido cambia la promesa de durabilidad.
Agregar réplicas no hace más rápida cada operación. Las lecturas también necesitan un protocolo: leer de un seguidor puede devolver datos desactualizados si no se usa una coordinación más fuerte.
Nombra la consistencia que necesitan los usuarios
La linealizabilidad (linearizability) hace que las operaciones parezcan ocurrir en un único orden que respeta la precedencia en tiempo real.
La consistencia eventual permite que las réplicas difieran temporalmente mientras buscan converger bajo sus suposiciones. Durante una partición de red, CAP dice que un sistema no puede garantizar a la vez la linealizabilidad y la disponibilidad, tal como se definen formalmente, para todas las peticiones. No es una regla para elegir dos letras a la ligera en operación normal.
Relay puede requerir un orden fuerte para las reservas de trabajo y aceptar reportes desactualizados. Elige por operación y luego explica qué viven los usuarios cuando la coordinación deja de estar disponible.
ERROR FRECUENTE
Una mayoría de nodos de almacenamiento no es un protocolo de consenso completo. Las elecciones, las reglas del log, la persistencia y las lecturas deben preservar las garantías requeridas.
INTÉNTALO TÚ
Divide un clúster de cinco nodos en grupos de tres y de dos. Identifica qué lado puede confirmar (commit) nuevas reservas respaldadas por quórum y describe el comportamiento visible para los usuarios del otro lado.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Escribe el contrato de consistencia de Relay para reservar trabajo, consultar estados y mostrar estadísticas agregadas. Especifica el comportamiento durante una partición.