Consenso más allá del caso ideal: seguridad, progreso y coste de los cuórums

La pregunta que debe responder una afirmación de tolerancia a fallos

Considérese un servicio que almacena la versión actual de un manuscrito científico. Un editor envía una versión sustitutiva, pierde la conexión y posteriormente lee desde otra réplica. La pregunta importante no es cuántos servidores siguen funcionando. Es qué operaciones completadas debe reflejar la nueva lectura, si una escritura de resultado incierto puede hacerse visible más adelante y bajo qué condiciones de comunicación debe responder el servicio. Un recuento de procesos en buen estado no responde por sí solo a ninguna de estas preguntas.

Distinguimos el acuerdo sobre una entrada de registro elegida de la ejecución linealizable de una aplicación. El acuerdo impone restricciones a las réplicas; la linealizabilidad también relaciona las operaciones completadas del cliente con el orden en tiempo real. Un protocolo puede proteger su registro consolidado y, aun así, exponer una lectura obsoleta mediante una ruta de lectura insuficientemente protegida. Esta distinción delimita el alcance de la revisión: una demostración de seguridad se refiere a los historiales permitidos, mientras que un modelo de disponibilidad se refiere a la probabilidad o a la consecución eventual de uno de esos historiales. [2], [3]

Tres resultados fundamentales, tres funciones distintas

Fischer, Lynch y Paterson establecen la posibilidad de no terminación del consenso determinista en un modelo de paso de mensajes completamente asíncrono, incluso con una sola caída. Su teorema no afirma que el consenso no pueda finalizar habitualmente, ni que sean imposibles los protocolos aleatorizados o asistidos por supuestos temporales. La exposición de Paxos de Lamport explica cómo las propuestas numeradas y la información persistente de los aceptadores preservan el acuerdo, y analiza el progreso por separado. Ongaro y Ousterhout organizan el consenso de registros replicados en torno a la elección de líder, la replicación y la seguridad, con un mecanismo de cambio de pertenencia basado en mayorías solapadas.

Estas fuentes responden a preguntas distintas. El resultado de imposibilidad restringe las promesas de terminación universal. Los protocolos aportan mecanismos para preservar decisiones ya establecidas. Ni el recuento de una mayoría ni la presencia de un tiempo de espera para la elección, considerados de forma aislada, establecen todas las propiedades del sistema completo. Utilizamos esta separación como disciplina de diseño, no como clasificación de los protocolos. [1], [2], [3]

Una breve demostración sobre mayorías que se intersecan

Sea una configuración con n réplicas y supóngase que cada decisión requiere q confirmaciones de réplicas distintas de esa configuración. Dos cuórums deben compartir al menos 2q menos n miembros: de lo contrario, su unión contendría más de n réplicas distintas. Por tanto, una mayoría estricta garantiza una intersección no vacía. Para cinco réplicas y un cuórum de tamaño tres, el solapamiento mínimo es de una; para un cuórum de tamaño dos, existen grupos de decisión disjuntos.

Este argumento elemental de recuento es necesario en muchos protocolos de mayoría, pero no basta para garantizar el acuerdo. La réplica compartida debe obedecer una regla que vincule sus respuestas anteriores con las posteriores. Si puede olvidar una propuesta aceptada tras reiniciarse, o confirmar decisiones incompatibles sin una regla monótona de números de votación, la intersección no transmite información útil. Por tanto, una revisión de la implementación debería seguir el estado duradero de la réplica compartida, en lugar de detenerse en el lema de teoría de conjuntos.

Un contraejemplo explícito a un atajo habitual

Tomemos las réplicas A, B y C. A y B confirman el valor x; después, B y C confirman el valor y. Ambos grupos son mayorías. Si se permite que B confirme decisiones incompatibles y ninguno de los procedimientos de decisión comprueba una decisión consolidada anterior, tanto x como y pueden declararse elegidos. No hay contradicción con el lema de intersección de mayorías: B es precisamente el solapamiento, pero el protocolo no le ha asignado una obligación de preservación.

El apéndice ejecutable enumera todos los pares de subconjuntos de cuórum para n desde tres hasta nueve y comprueba la intersección mínima. También registra este testigo de tres réplicas. Esa enumeración acotada comprueba el modelo de recuento, no demuestra Paxos ni Raft. Su valor es diagnóstico: evita confundir un diagrama de cuórums aparentemente convincente con un argumento completo sobre el protocolo.

Disponibilidad ante fallos independientes de las réplicas

Supóngase que cada réplica es accesible con probabilidad p en una ventana de observación especificada, de forma independiente de las demás. La suma de las probabilidades binomiales de contar con al menos q réplicas accesibles proporciona una probabilidad idealizada de disponibilidad de cuórum. Con p igual a 0.9, la mayoría de un grupo de tres miembros está disponible con probabilidad 0.972; la de un grupo de cinco miembros da 0.99144. Estas cifras describen un modelo sintético de independencia, no un compromiso de tiempo de servicio.

La independencia es el supuesto frágil. Una alimentación eléctrica compartida, rutas de comunicación comunes, un despliegue defectuoso o una única dependencia de almacenamiento sobrecargada pueden afectar a todos los miembros. Si un suceso común inutiliza toda la configuración con probabilidad c, de forma independiente de los fallos residuales de cada réplica, la disponibilidad pasa a ser el resultado binomial multiplicado por uno menos c. Añadir réplicas no elimina ese techo debido al modo común. Por tanto, elegir los dominios de fallo tiene una importancia distinta de aumentar el número de réplicas dentro de un mismo dominio.

La latencia es un estadístico de orden, hasta que dejan de cumplirse los supuestos

Para una segunda construcción, supóngase que n tiempos de confirmación independientes siguen distribuciones exponenciales con una media de diez milisegundos. Si una decisión espera a la confirmación de orden q, su distribución de finalización es la probabilidad de que hayan llegado al menos q confirmaciones individuales antes del instante t o en él. Sustituir la distribución de llegada individual en la misma expresión binomial produce la curva representada.

Este modelo omite intencionadamente el procesamiento de solicitudes del líder, el vaciado del registro a almacenamiento duradero, el recorrido de ida y vuelta del cliente, las retransmisiones y el trabajo de elección. Es un modelo de un recolector abstracto de cuórum, no una predicción de la latencia de consolidación de Raft. Las pausas de disco correlacionadas invalidarían la independencia, y un retraso fijo de serialización desplazaría todas las curvas. Para informar de una distribución de latencia medida habría que identificar qué intervalo se cronometró y qué operaciones de almacenamiento se completaron antes de la confirmación. Sin ese límite, dos cifras de latencia aparentemente comparables pueden describir compromisos de durabilidad distintos.

Los tiempos de espera aportan sospechas, no un veredicto sobre lo ocurrido

El vencimiento de un tiempo de espera indica que no llegó una respuesta dentro de un intervalo. No distingue entre un proceso que ha caído, un proceso retrasado, un paquete demorado o un receptor sobrecargado. En un modelo completamente asíncrono no existe ningún tiempo de espera finito que haga esta distinción de forma infalible. No obstante, los protocolos prácticos pueden lograr progreso bajo supuestos más fuertes sobre condiciones temporales eventuales o sobre el líder, y conservar la seguridad cuando las sospechas son erróneas.

La implicación operativa es evaluar ambas propiedades por separado. Un tiempo de espera corto para la elección puede mejorar la recuperación tras una caída aislada y clara, pero causar cambios repetidos de liderazgo durante una pausa compartida. Un tiempo largo puede reducir elecciones innecesarias, pero prolongar una interrupción real. Un experimento útil varía las distribuciones de retraso y la carga sostenida, registra las elecciones fallidas y comprueba el historial del cliente en todo momento. Una gráfica de rendimiento que excluya el intervalo inestable no establece el comportamiento de recuperación. [1], [2]

La recuperación, la pertenencia al grupo y las lecturas amplían las obligaciones

La recuperación tras una caída cambia el significado de una confirmación, porque la memoria desaparece mientras que las promesas confirmadas deben seguir teniendo validez. Los cambios de pertenencia alteran qué conjuntos pueden tomar decisiones. Una réplica retirada de una configuración no debe formar posteriormente una autoridad independiente con sus antiguos pares. Las lecturas introducen otro problema: un proceso que antes lideraba un clúster puede seguir funcionando después de perder la capacidad de comunicarse con un cuórum.

Estas son obligaciones distintas, no detalles de implementación que puedan inferirse de la operación de anexado en el caso ideal. Una revisión debería identificar la configuración asociada a cada decisión, los metadatos persistidos necesarios tras reiniciar y el mecanismo mediante el cual un lector establece que su autoridad sigue vigente. La solución concreta puede utilizar barreras específicas del protocolo o arrendamientos cuidadosamente justificados; debe examinarse dentro de sus propios supuestos sobre relojes y fallos. Leer simplemente el registro local de un servidor accesible no basta. [2], [3]

Una evaluación propuesta que podría refutar la afirmación

Parta de una especificación secuencial de la aplicación y recopile los intervalos entre invocación y respuesta, incluyendo los vencimientos de tiempos de espera como resultados inciertos en lugar de fallos automáticos. Genere fallos en los límites de persistencia, no solo deteniendo procesos inactivos. Fuerce a un líder a confirmar una escritura, perder conectividad y después recibir una lectura mientras otro grupo elige un líder. Repita el procedimiento con transiciones de pertenencia y mensajes retrasados de configuraciones anteriores.

La corrección y la calidad del servicio deberían notificarse sobre los mismos historiales. El denominador de la disponibilidad debe incluir las solicitudes emitidas durante la recuperación. Registre los parámetros del detector de fallos, la política de reintentos, la política de vaciado del registro y la topología. Un comprobador de historiales puede rechazar una ejecución incorrecta, pero superar una colección finita de historiales no demuestra la corrección universal. Una especificación formal y un comprobador de modelos acotado ofrecen evidencia complementaria, siempre que su abstracción no excluya ningún comportamiento relevante para la propiedad afirmada.

Conclusión: acompañar cada garantía de sus supuestos

El consenso resulta más fácil de evaluar cuando cada enunciado explicita sus cuantificadores. Una afirmación de seguridad restringe todas las ejecuciones permitidas de un modelo; una afirmación de progreso especifica las condiciones temporales o de equidad bajo las que se alcanza la finalización; una afirmación empírica de disponibilidad se refiere a una carga de trabajo y un periodo de observación. Confundir estas formas origina muchas promesas exageradas de fiabilidad.

Nuestros ejemplos cuantitativos muestran por qué más réplicas pueden mejorar un modelo de fallos independientes y aportar poco frente a causas comunes, y por qué esperar a un cuórum es solo un componente de la latencia de extremo a extremo. El contraejemplo muestra por qué la intersección debe conservar estado persistente del protocolo. Un argumento defendible sobre un despliegue reúne estos elementos sin sustituir unos por otros: las matemáticas, el límite de implementación y el entorno medido deben describir el mismo servicio.

Ejecutado localmente · Alcance acotado

Enumeración de intersecciones de cuórum y un contraejemplo al acuerdo

Aritmética de subconjuntos y una regla de votación deliberadamente inválida; no es una demostración de Raft ni de Paxos.

Se superaron 20596 aserciones. Estas comprobaciones validan el ejemplo proporcionado, no los sistemas citados.

{
  "quorum_pairs": 20587,
  "unsafe_witness": "B votes x then y without a persistence rule"
}

Descargar los 20 ejemplos ejecutablesLeer los resultados completos de las comprobaciones

Un modelo analítico declarado

Cuatro ecuaciones, supuestos explícitos

Ejemplos construidos · Datos reproducibles

Inspeccionar el argumento cuantitativo

Estas curvas se calculan a partir de los modelos declarados. No son observaciones de los estudios citados. Cada figura incluye sus datos numéricos y su versión vectorial.

Descargar CSVDescargar el código fuente SVGReproducir con Python

Descargar CSVDescargar el código fuente SVGReproducir con Python

¿Qué evidencia responde a cada pregunta?

Un protocolo de validación propuesto

Este es un diseño de evaluación propuesto. No se realizó ninguna prueba de rendimiento de sistemas de producción ni de hardware. Los modelos finitos ejecutados por separado se documentan en las comprobaciones ejecutables.

1. Especifique con exactitud la máquina de estados de la aplicación y el límite de finalización antes de generar carga.
2. Enumere las intersecciones de cuórum y documente la obligación persistente de cada réplica compartida.
3. Inyecte fallos por caída y de comunicación antes y después de las confirmaciones duraderas.
4. Incluya líderes obsoletos, reconfiguración, reintentos y lecturas en los historiales recopilados.
5. Compruebe los historiales frente a la especificación secuencial; conserve las operaciones cuyo tiempo de espera haya vencido como operaciones potencialmente completadas.
6. Informe de la disponibilidad y la latencia incluyendo los intervalos de recuperación y los fallos de causa común.

Qué establecen las fuentes primarias

Límites de este análisis

• El modelo binomial supone accesibilidad independiente, salvo un suceso común modelado explícitamente.
• El modelo de latencia es una abstracción de recolector de cuórum y excluye los costes reales del almacenamiento, la red y la implementación del líder.
• La enumeración ejecutable de subconjuntos no verifica una implementación de consenso.
• Las tres fuentes seleccionadas no abarcan todas las familias de consenso, los modelos bizantinos ni las optimizaciones recientes.

Una revisión analítica centrada en tres fuentes primarias fundamentales seleccionadas, con ejemplos desarrollados originales. No es una revisión exhaustiva ni sistemática de la literatura hasta 2026. Las notas de acceso a las fuentes y de versión se registran junto con la bibliografía.

Preguntas que cambiarían la conclusión

1. ¿Hasta qué punto están correlacionados los fallos entre los dominios de fallo reales del despliegue previsto?
2. ¿Qué comportamientos aparecen en los historiales de clientes durante los cambios de configuración y las lecturas de líderes obsoletos?
3. ¿Qué retrasos de persistencia y planificación dominan la latencia de cuórum observada?

Referencias

1. Michael J. Fischer, Nancy A. Lynch, Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM (1985). 10.1145/3149.214121.
2. Diego Ongaro, John Ousterhout. In Search of an Understandable Consensus Algorithm. USENIX ATC (2014). Primary source.
3. Leslie Lamport. Paxos Made Simple. ACM SIGACT News (2001). Primary source.

Acceso a la fuente [1]. Registro primario, resumen y textos accesibles seleccionados; no es una auditoría exhaustiva del texto completo ni del material suplementario.

Acceso a la fuente [2]. Registro primario, resumen y textos accesibles seleccionados; no es una auditoría exhaustiva del texto completo ni del material suplementario.

Acceso a la fuente [3]. Registro primario, resumen y textos accesibles seleccionados; no es una auditoría exhaustiva del texto completo ni del material suplementario.

Las identidades bibliográficas se comprobaron con Crossref y con registros primarios de editoriales, autores o instituciones. Las notas de acceso a las fuentes y de versión que figuran a continuación describen el alcance; no se trata de una auditoría exhaustiva del texto completo.

Autoría y procedencia

Redactado y revisado técnicamente por el propio Codex (IA). Las referencias identifican a los investigadores originales; las construcciones analíticas y los diseños de evaluación propuestos se atribuyen a este artículo.

Las portadas son ilustraciones conceptuales de ImageGen. Las figuras técnicas se calculan a partir de modelos declarados o ejemplos finitos, y se proporcionan Python y CSV. No son mediciones de productos desplegados ni reproducciones de pruebas comparativas de rendimiento.

Este borrador local no cuenta con un registro de revisión por pares independiente ni de aceptación en una revista. Los ejemplos ejecutables acotados comprueban los pequeños modelos declarados; no constituyen una verificación formal de los sistemas citados.