Computación en la nube y centros de datos

Cloudflare adopta el algoritmo QuePaxa para resolver el dilema del consenso distribuido en redes globales

Cloudflare se orienta hacia la adopción del algoritmo de consenso no tradicional QuePaxa para operar su servicio Meerkat de gestión del plano de control global, superando a los algoritmos tradicionales como Raft y Paxos para sortear los problemas de fallo de líderes y la fluctuación en la respuesta de redes de área amplia.

2026-11-11
5 min de lectura
0 visitas
certi.news Editorial Team
Cloudflare adopta el algoritmo QuePaxa para resolver el dilema del consenso distribuido en redes globales

Cloudflare ha revelado detalles de ingeniería relacionados con su servicio experimental de consenso distribuido Meerkat, diseñado para gestionar el plano de control interno (Control Plane) a escala global. El servicio se basa en un moderno algoritmo de consenso llamado QuePaxa, publicado por los investigadores "Tennage y Băsescu" en 2023. Esta elección representa una ruptura con lo habitual en el campo de los sistemas distribuidos, donde la mayoría de las infraestructuras actuales dependen de algoritmos consolidados como Raft, Paxos o Viewstamped Replication.

Desafíos de los algoritmos de consenso tradicionales en redes globales

Los algoritmos de consenso tradicionales sufren una fuerte caída de rendimiento o una interrupción total del servicio cuando operan a través de redes de área amplia (WAN) caracterizadas por una latencia fluctuante y posibles interrupciones de la conectividad. Estos protocolos dependen fundamentalmente de la existencia de un nodo líder (Leader Process) que garantice el orden de las operaciones y entregue respuestas en un tiempo previsible. Cuando el líder experimenta un aumento en la latencia o pierde la conexión con la red, las operaciones de consenso se detienen por completo hasta que se detecta el fallo y se elige un nuevo líder.

Los principales defectos de los sistemas tradicionales se materializan en dos puntos críticos:

  • Interferencia destructiva (Destructive Interference): En el protocolo Paxos, la presentación de propuestas simultáneas por parte de varios nodos provoca la anulación mutua de las propuestas y entra en una espiral de intentos fallidos que paralizan el progreso del sistema. Aunque el protocolo Raft resuelve el problema designando un único líder, la interferencia destructiva reaparece durante los procesos de elección de líder cuando se produce una perturbación temporal de la red.
  • Detectores de fallos deficientes (Fault Detectors): En redes asíncronas como Internet, es difícil distinguir entre la lentitud de la red y el fallo total de un nodo. Las estimaciones erróneas de los detectores de fallos desencadenan procesos innecesarios de elección de líder, lo que introduce al sistema en un estado de fallo similar al de estabilidad metaestable (Metastable Failure) y detiene las escrituras durante varias horas.

¿Cómo aborda QuePaxa los puntos débiles sin un líder obligatorio?

El algoritmo QuePaxa supera estos obstáculos a través de tres opciones de diseño fundamentales: hacer que el líder sea una opción opcional, prescindir por completo de los detectores de fallos y basarse en la cooperación en lugar de la competencia entre los proponentes (Proposers). El algoritmo se basa en la división de roles entre los candidatos (Proposers) y los registradores (Recorders).

El algoritmo se basa en asignar prioridades aleatorias a las propuestas. Cuando un proponente recibe una propuesta con una mayor prioridad que la de otro registrador, adopta la nueva propuesta de inmediato y comienza a difundirla, lo que hace que todos los nodos trabajen cooperativamente para alcanzar la mayor prioridad anunciada en lugar de bloquearse mutuamente. En caso de que exista un líder, se le asigna la mayor prioridad posible, lo que le permite resolver el consenso en un solo viaje de ida y vuelta (Single Round-Trip) siempre que la red sea estable.

Mecánica de funcionamiento técnico: Las cuatro fases para lograr el consenso

QuePaxa ejecuta las rondas de consenso a través de cuatro fases consecutivas por las que pasa el sistema para aprobar los registros:

  • Fase 0 (Presentación y adopción): Los proponentes generan prioridades aleatorias para sus propuestas. Si el líder funciona correctamente y sus mensajes llegan primero a la mayoría de los registradores, el consenso se resuelve de inmediato a través del "camino rápido" (Fast Path).
  • Fase 1 (Difusión): Los proponentes difunden las propuestas adoptadas a la mayoría de los registradores para evitar la reversión posterior de las propuestas con prioridades más altas, basándose en la intersección de mayorías (Majority Intersection).
  • Fase 2 (Verificación y resolución): Los proponentes consultan a los registradores sobre la prioridad más alta vista en la fase anterior y, si coincide con su propuesta adoptada, se aprueba formalmente.
  • Fase 3 (Paso a la siguiente ronda): En caso de no resolverse, los nodos adoptan la mejor propuesta disponible en preparación para la siguiente ronda, lo que eleva drásticamente la probabilidad de consenso acumulativo.

¿Por qué importa esta transformación técnica?

La adopción de QuePaxa es un paso práctico que cambia la forma en que se diseñan los sistemas distribuidos intercontinentales; demuestra que los sistemas no necesitan sacrificar la disponibilidad (Availability) ni sufrir paradas totales ante una perturbación de Internet. Los resultados de la ejecución de Meerkat en el entorno real de Cloudflare mostraron que más del 95% de las decisiones se resuelven a través del camino rápido del líder y, cuando se produce un fallo en la red o cae el líder, el sistema no se detiene, sino que su tasa de rendimiento se reduce a un tercio como máximo mientras continúa procesando solicitudes.

El algoritmo también permite técnicas de cobertura (Hedging), donde los clientes pueden enviar propuestas a todas las réplicas configurando un breve tiempo de espera localmente sin estar atados a la latencia de la red, eliminando los periodos de inactividad causados por los largos tiempos de espera de elección en Raft, que alcanzan varios segundos. Cloudflare trabaja actualmente en la verificación formal (Formal Verification) del código del algoritmo escrito en lenguaje Rust para garantizar la seguridad de los datos durante los estados de recuperación de fallos (Crash Recovery).

Fuente de la noticia
Cloudflare Blog
Abrir fuente original ↗
c
Autor

certi.news Editorial Team

De la misma categoría

También te puede interesar

Ver todas las noticias