{"id":37335,"date":"2019-10-31T22:17:01","date_gmt":"2019-10-31T19:17:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kot-shryodingera-bez-korobki-problema-konsensusa-v-raspredelyonnyh-sistemah\/"},"modified":"2019-10-31T22:17:01","modified_gmt":"2019-10-31T19:17:01","slug":"kot-shryodingera-bez-korobki-problema-konsensusa-v-raspredelyonnyh-sistemah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kot-shryodingera-bez-korobki-problema-konsensusa-v-raspredelyonnyh-sistemah","title":{"rendered":"El gato de Schr\u00f6dinger sin caja: el problema del consenso en sistemas distribuidos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Imaginemos. En una habitaci\u00f3n hay 5 gatos encerrados, y para ir a despertar a su due\u00f1o, necesitan ponerse de acuerdo entre ellos, ya que solo pueden abrir la puerta si empujan todos juntos. Si uno de los gatos es el gato de Schr\u00f6dinger, y los dem\u00e1s no saben sobre su decisi\u00f3n, surge la pregunta: \"\u00bfC\u00f3mo pueden lograrlo?\" <\/p>\n

En este art\u00edculo, explicar\u00e9 en un lenguaje sencillo la parte te\u00f3rica del mundo de los sistemas distribuidos y los principios de su funcionamiento. Tambi\u00e9n examinar\u00e9 superficialmente la idea principal que subyace en Paxos. <\/p>\n

\"El
\n<\/a><\/noindex>
\nCuando los desarrolladores utilizan infraestructuras en la nube, diversas bases de datos y trabajan en cl\u00fasteres de muchos nodos, est\u00e1n seguros de que los datos ser\u00e1n \u00edntegros, seguros y siempre accesibles. Pero, \u00bfde d\u00f3nde vienen esas garant\u00edas?<\/p>\n

En esencia, las garant\u00edas que tenemos son las garant\u00edas del proveedor. Est\u00e1n descritas en la documentaci\u00f3n de la siguiente manera: \"Este servicio es lo suficientemente confiable, tiene un SLA establecido, no se preocupe, todo funcionar\u00e1 distribuido como usted espera.\" <\/p>\n

Tendemos a creer en lo mejor, ya que los directores de grandes empresas nos aseguraron que todo estar\u00e1 bien. No nos hacemos la pregunta: \u00bfpor qu\u00e9, en realidad, esto puede funcionar? \u00bfHay alguna justificaci\u00f3n formal para el correcto funcionamiento de tales sistemas?<\/p>\n

Recientemente fui a una escuela sobre computaci\u00f3n distribuida<\/a><\/noindex> y me inspir\u00e9 mucho en esta tem\u00e1tica. Las conferencias en la escuela se parec\u00edan m\u00e1s a clases de an\u00e1lisis matem\u00e1tico que a algo relacionado con sistemas inform\u00e1ticos. Pero as\u00ed es como se demostraron los algoritmos m\u00e1s importantes que usamos todos los d\u00edas, sin que siquiera lo sospechemos. <\/p>\n

En la mayor\u00eda de los sistemas distribuidos modernos se usa el algoritmo de consenso Paxos y sus diversas modificaciones. Lo m\u00e1s impresionante es que la fundamentaci\u00f3n y, en principio, la posibilidad misma de la existencia de este algoritmo pueden demostrarse f\u00e1cilmente con solo un bol\u00edgrafo y papel. Al mismo tiempo, el algoritmo se aplica en grandes sistemas que funcionan en un gran n\u00famero de nodos en la nube. <\/p>\n

Una ilustraci\u00f3n ligera de lo que se tratar\u00e1 a continuaci\u00f3n: el problema de los dos generales<\/b>Para calentar, analicemos el problema de los dos generales<\/a><\/noindex>. <\/p>\n

Tenemos dos ej\u00e9rcitos: el rojo y el blanco. Las tropas blancas est\u00e1n acantonadas en la ciudad sitiada. Las tropas rojas, lideradas por los generales A1 y A2, se encuentran a ambos lados de la ciudad. La tarea de los rojos es atacar la ciudad blanca y ganar. Sin embargo, el ej\u00e9rcito de cada general rojo es m\u00e1s peque\u00f1o que el de los blancos.<\/p>\n

\"El
\n
\nLas condiciones para que los rojos ganen son: ambos generales deben atacar al mismo tiempo para tener superioridad num\u00e9rica sobre los blancos. Para ello, los generales A1 y A2 necesitan llegar a un acuerdo entre ellos. Si cada uno ataca por separado, los rojos perder\u00e1n. <\/p>\n

Para llegar a un acuerdo, los generales A1 y A2 pueden enviar mensajeros a trav\u00e9s del territorio de la ciudad blanca. Un mensajero puede llegar con \u00e9xito al general aliado o puede ser interceptado por el enemigo. La pregunta es: \u00bfexiste una secuencia de comunicaciones entre los generales rojos (una secuencia de env\u00edos de mensajeros de A1 a A2 y viceversa, de A2 a A1) en la que se aseguren de acordar un ataque a la hora X? Aqu\u00ed, por garant\u00edas se entiende que ambos generales tendr\u00e1n una confirmaci\u00f3n inequ\u00edvoca de que su aliado (el otro general) atacar\u00e1 exactamente a la hora acordada X.<\/p>\n

Supongamos que A1 env\u00eda un mensajero a A2 con el mensaje: '\u00a1Atacamos hoy a la medianoche!'. El general A1 no puede atacar sin la confirmaci\u00f3n del general A2. Si el mensajero de A1 llega, el general A2 env\u00eda su confirmaci\u00f3n con el mensaje: 'S\u00ed, vamos a derribar a los blancos hoy'. Pero ahora el general A2 no sabe si su mensajero lleg\u00f3 o no, no tiene garant\u00edas de que el ataque sea simult\u00e1neo. Ahora, el general A2 necesita otra vez una confirmaci\u00f3n.<\/p>\n

Si se detalla a\u00fan m\u00e1s su comunicaci\u00f3n, se descubrir\u00e1 lo siguiente: por mucho que haya ciclos de intercambio de mensajes, no hay forma de garantizar que ambos generales sean notificados de que sus mensajes han sido recibidos (suponiendo que cualquiera de los mensajeros pueda ser interceptado).<\/p>\n

La tarea de los dos generales es una excelente ilustraci\u00f3n de un sistema distribuido muy simple, donde hay dos nodos con comunicaci\u00f3n poco fiable. As\u00ed que no tenemos una garant\u00eda del 100% de que se sincronicen. Sobre problemas similares, pero en una escala mayor, se hablar\u00e1 m\u00e1s adelante en el art\u00edculo.<\/p>\n

Introducimos el concepto de sistemas distribuidos.<\/h2>\n

\nUn sistema distribuido es un conjunto de computadoras (a partir de ahora las llamaremos nodos) que pueden intercambiar mensajes. Cada nodo individual es una entidad aut\u00f3noma. Un nodo puede procesar tareas de manera independiente, pero para interactuar con otros nodos, necesita enviar y recibir mensajes. <\/p>\n

C\u00f3mo se implementan exactamente los mensajes y qu\u00e9 protocolos se utilizan no nos interesa en este contexto. Lo importante es que los nodos del sistema distribuido pueden intercambiar datos entre s\u00ed enviando mensajes.<\/p>\n

La propia definici\u00f3n no parece muy complicada, pero hay que tener en cuenta que un sistema distribuido tiene una serie de atributos que ser\u00e1n importantes para nosotros.<\/p>\n

Atributos de los sistemas distribuidos<\/h4>\n

<\/p>\n

    \n
  1. Concurrencia<\/b> es la posibilidad de que ocurran eventos simult\u00e1neos o concurrentes en el sistema. M\u00e1s a\u00fan, consideraremos que los eventos que ocurren en dos nodos diferentes son potencialmente concurrentes hasta que tengamos un orden claro en el que esos eventos suceden. Y, por lo general, no lo tenemos.<\/li>\n
  2. Ausencia de relojes globales<\/b>. No tenemos un orden claro de los eventos debido a la ausencia de relojes globales. En el mundo normal de los humanos, estamos acostumbrados a tener relojes y tiempo absoluto. Todo cambia cuando hablamos de sistemas distribuidos. Incluso los relojes at\u00f3micos m\u00e1s precisos tienen un desv\u00edo, y pueden surgir situaciones en las que no podemos decir cu\u00e1l de los dos eventos ocurri\u00f3 primero. Por lo tanto, tambi\u00e9n no podemos confiar en el tiempo.<\/li>\n
  3. Fallo independiente de los nodos del sistema<\/b>. Hay otro problema: algo puede salir mal simplemente porque nuestros nodos no son eternos. Un disco duro puede fallar, una m\u00e1quina virtual en la nube puede reiniciarse, puede haber un parpadeo en la red y los mensajes se pierden. Adem\u00e1s, es posible que haya situaciones en las que los nodos funcionen, pero en contra del sistema. Esta \u00faltima clase de problemas incluso tiene un nombre espec\u00edfico: el problema de los generales bizantinos<\/a><\/noindex>. El ejemplo m\u00e1s popular de un sistema distribuido con este problema es el Blockchain. Pero hoy no vamos a considerar esta clase especial de problemas. Nos interesar\u00e1n las situaciones en las que uno o varios nodos pueden fallar.<\/li>\n
  4. Modelos de comunicaci\u00f3n (modelos de intercambio de mensajes) entre nodos<\/b>. Ya hemos determinado que los nodos se comunican mediante el intercambio de mensajes. Hay dos modelos de intercambio de mensajes conocidos: s\u00edncrono y as\u00edncrono.<\/li>\n<\/ol>\n

    <\/p>\n

    Modelos de comunicaci\u00f3n entre nodos en sistemas distribuidos<\/h4>\n

    \nModelo s\u00edncrono<\/b> \u2013 sabemos con certeza que hay una delta de tiempo finita conocida, durante la cual el mensaje llega garantizado de un nodo a otro. Si este tiempo ha pasado y no ha llegado el mensaje, podemos afirmar con confianza que el nodo ha fallado. En este modelo, tenemos un tiempo de espera predecible. <\/p>\n

    Modelo as\u00edncrono<\/b> \u2013 en los modelos as\u00edncronos consideramos que el tiempo de espera es finito, pero no existe tal delta de tiempo despu\u00e9s de la cual se puede garantizar que un nodo ha fallado. Es decir, el tiempo de espera del mensaje de un nodo puede ser arbitrariamente largo. Esta es una definici\u00f3n importante, y hablaremos de ello m\u00e1s adelante. <\/p>\n

    El concepto de consenso en sistemas distribuidos<\/h2>\n

    \nAntes de definir formalmente el concepto de consenso, consideremos un ejemplo de situaci\u00f3n en la que lo necesitamos, a saber \u2013 Replicaci\u00f3n de M\u00e1quina de Estado<\/b>. <\/p>\n

    Tenemos un registro distribuido. Nos gustar\u00eda que fuera consistente y contuviera datos id\u00e9nticos en todos los nodos del sistema distribuido. Cuando alguno de los nodos conoce un nuevo valor que va a registrar en el log, su tarea es proponer este valor a todos los dem\u00e1s nodos, para que el log se actualice en todos los nodos, y el sistema pase a un nuevo estado consistente. Es importante que los nodos se pongan de acuerdo: todos los nodos deben estar de acuerdo en que el nuevo valor propuesto es correcto, todos los nodos deben aceptar este valor, y solo en este caso todos pueden registrar el nuevo valor en el log. <\/p>\n

    En otras palabras: ninguno de los nodos objet\u00f3 que tuviera informaci\u00f3n m\u00e1s actualizada, ni que el valor propuesto fuera incorrecto. El acuerdo entre los nodos y el consenso sobre el valor \u00fanico correcto aceptado es el consenso en el sistema distribuido. M\u00e1s adelante hablaremos sobre los algoritmos que permiten al sistema distribuido alcanzar el consenso de manera garantizada.
    \n\"El
    \nDe manera m\u00e1s formal, podemos definir el algoritmo de consenso (o simplemente el algoritmo de consenso) como una funci\u00f3n que lleva a un sistema distribuido de un estado A a un estado B. Adem\u00e1s, este estado es aceptado por todos los nodos, y todos los nodos pueden confirmarlo. Como se descubre, esta tarea no es tan trivial como parece a primera vista.<\/p>\n

    Propiedades del algoritmo de consenso<\/h4>\n

    \nUn algoritmo de consenso debe poseer tres propiedades para que el sistema contin\u00fae existiendo y tenga alg\u00fan progreso al pasar de un estado a otro:<\/p>\n

      \n
    1. Acuerdo <\/b> \u2013 todos los nodos que funcionan correctamente deben aceptar el mismo valor (en los art\u00edculos, esta propiedad tambi\u00e9n se conoce como propiedad de seguridad). Todos los nodos que est\u00e1n funcionando en este momento (que no han fallado y no han perdido conexi\u00f3n con los dem\u00e1s) deben llegar a un acuerdo y aceptar un valor com\u00fan final.\n

      Aqu\u00ed es importante entender que los nodos en el sistema distribuido que estamos considerando quieren llegar a un acuerdo. Es decir, estamos hablando de sistemas donde algo puede fallar (por ejemplo, un nodo puede fallar), pero en este sistema no hay nodos que intencionalmente trabajen en contra de otros (la tarea de los generales bizantinos). Por esta propiedad, el sistema se mantiene consistente.<\/li>\n

    2. Integridad <\/b> \u2014 si todos los nodos que funcionan correctamente proponen el mismo valor v<\/b>, entonces cada nodo que funcione correctamente debe aceptar este valor v<\/b>. <\/li>\n
    3. Terminaci\u00f3n <\/b>\u2013 todos los nodos que funcionan correctamente eventualmente aceptar\u00e1n alg\u00fan valor (propiedad de vivacidad), lo que permite que el algoritmo tenga progreso en el sistema. Cada nodo que funcione correctamente debe, tarde o temprano, aceptar un valor final y confirmarlo: \"Para m\u00ed, este valor es verdadero, estoy de acuerdo con todo el sistema\".<\/li>\n<\/ol>\n

      <\/p>\n

      Ejemplo del funcionamiento del algoritmo de consenso<\/h4>\n

      \nMientras que las propiedades del algoritmo pueden no ser del todo claras. Por lo tanto, ilustraremos con un ejemplo las etapas que pasa el algoritmo de consenso m\u00e1s simple en un sistema con un modelo de intercambio de mensajes s\u00edncrono, donde todos los nodos funcionan como se espera, los mensajes no se pierden y nada se rompe (\u00bfrealmente sucede eso?).<\/p>\n

        \n
      1. Todo comienza con una proposici\u00f3n de mano y coraz\u00f3n (Propose). Supongamos que un cliente se ha conectado al nodo llamado \"Nodo 1\" y ha comenzado una transacci\u00f3n, enviando un nuevo valor al nodo: O. A partir de este momento, llamaremos a \"Nodo 1\" proposer<\/b>. Como proposer, \"Nodo 1\" ahora debe notificar a todo el sistema que tiene nuevos datos, y env\u00eda mensajes a todos los dem\u00e1s nodos: \"\u00a1Miren! He recibido el valor \"O\", \u00a1y quiero que lo guarden! Por favor, confirmen que ustedes tambi\u00e9n guardar\u00e1n \"O\" en su registro.\"\n

        \"El<\/li>\n

      2. La siguiente etapa es la votaci\u00f3n del valor propuesto (Voting). \u00bfPara qu\u00e9 sirve? Puede suceder que otros nodos hayan recibido informaci\u00f3n m\u00e1s reciente y tengan datos sobre esta misma transacci\u00f3n.\n

        \"El
        \n
        \nCuando el nodo \"Nodo 1\" env\u00eda su propuesta, los dem\u00e1s nodos revisan sus registros para este evento. Si no hay inconsistencias, los nodos declaran: \"S\u00ed, no tengo otros datos sobre este evento. El valor \"O\" es la informaci\u00f3n m\u00e1s reciente que hemos recibido.\" <\/p>\n

        En cualquier otro caso, los nodos pueden responder a \"Nodo 1\": \"\u00a1Escucha! Tengo datos m\u00e1s recientes sobre esta transacci\u00f3n. No es \"O\", sino algo mejor.\"<\/p>\n

        Durante la fase de votaci\u00f3n, los nodos llegan a una decisi\u00f3n: o todos aceptan un \u00fanico valor, o alguno de ellos vota en contra, indicando que tiene datos m\u00e1s recientes. <\/li>\n

      3. Si la ronda de votaci\u00f3n ha sido exitosa y todos estuvieron a favor, el sistema pasa a una nueva etapa: la aceptaci\u00f3n del valor (Accept). \"Nodo 1\" re\u00fane todas las respuestas de los otros nodos y declara: \"\u00a1Todos han aceptado el valor \"O\"! Ahora anuncio oficialmente que \"O\" es nuestro nuevo valor, \u00a1el mismo para todos! Anoten en su cuadernito, no se olviden. \u00a1Reg\u00edstrenlo en su log!\"\n

        \"El<\/li>\n

      4. Los dem\u00e1s nodos env\u00edan una confirmaci\u00f3n (Accepted) de que han registrado el valor \"O\", sin que haya llegado nada nuevo en este tiempo (una especie de compromiso de dos fases). Despu\u00e9s de este evento significativo, consideramos que la transacci\u00f3n distribuida se ha completado.
        \n \"El <\/li>\n<\/ol>\n

        \nAs\u00ed, el algoritmo de consenso en un caso simple consta de cuatro pasos: proponer, votar (voting), aceptar (accept) y confirmar aceptaci\u00f3n (accepted).<\/p>\n

        Si en alg\u00fan paso no logramos alcanzar un consenso, el algoritmo se reinicia, teniendo en cuenta la informaci\u00f3n que proporcionar\u00e1n los nodos que se negaron a confirmar el valor propuesto.<\/p>\n

        El algoritmo de consenso en un sistema as\u00edncrono<\/h2>\n

        \nHasta ahora, todo hab\u00eda sido simple, ya que est\u00e1bamos hablando de un modelo de intercambio de mensajes sincr\u00f3nico. Pero sabemos que en el mundo moderno estamos acostumbrados a hacer todo de manera as\u00edncrona. \u00bfC\u00f3mo funciona un algoritmo similar en un sistema con un modelo de intercambio de mensajes as\u00edncrono, donde consideramos que el tiempo de espera para recibir una respuesta de un nodo puede ser indefinidamente largo? (Por cierto, la falla de un nodo tambi\u00e9n se puede considerar un ejemplo en el que un nodo puede responder durante un tiempo indefinido). <\/p>\n

        Ahora que entendemos c\u00f3mo funciona, en t\u00e9rminos generales, el algoritmo de consenso, planteo una pregunta a los lectores curiosos que han llegado hasta aqu\u00ed: \u00bfcu\u00e1ntos nodos en un sistema de N nodos con un modelo de mensajes as\u00edncrono pueden fallar para que el sistema a\u00fan pueda alcanzar el consenso?<\/p><\/blockquote>\n

        \nLa respuesta correcta y su justificaci\u00f3n se encuentran tras el spoiler.<\/b>La respuesta correcta es: 0<\/b>. Si al menos un nodo en un sistema as\u00edncrono falla, el sistema no podr\u00e1 alcanzar consenso. Esta afirmaci\u00f3n est\u00e1 demostrada en un teorema bien conocido en ciertos c\u00edrculos, el teorema FLP (1985, Fischer, Lynch, Paterson, enlace al original al final del art\u00edculo): \"La imposibilidad de alcanzar consenso distribuido con la falla de al menos un nodo\".
        \n\"El
        \nChicos, entonces tenemos un problema, estamos acostumbrados a que todo sea as\u00edncrono. \u00bfY ahora qu\u00e9 hacemos? \u00bfC\u00f3mo seguimos adelante? <\/p>\n

        Ahora est\u00e1bamos hablando de teor\u00eda, de matem\u00e1ticas. \u00bfQu\u00e9 significa \"el consenso no puede ser alcanzado\" cuando lo traducimos de lenguaje matem\u00e1tico a nuestro lenguaje ingenieril? Significa que \"no siempre puede ser alcanzado\", es decir, existe un caso en el que el consenso no es alcanzable. \u00bfY cu\u00e1l es este caso? <\/p>\n

        Eso es precisamente lo que se describe como la violaci\u00f3n de la propiedad de liveness, mencionada anteriormente. No tenemos un acuerdo com\u00fan, y el sistema no puede tener progreso (no puede completarse en un tiempo finito) si no recibimos respuestas de todos los nodos. Porque en un sistema as\u00edncrono no tenemos un tiempo de respuesta predecible, y no podemos saber si un nodo ha fallado o simplemente est\u00e1 respondiendo lentamente.<\/p>\n

        Pero en la pr\u00e1ctica podemos encontrar una soluci\u00f3n. Supongamos que nuestro algoritmo puede funcionar durante mucho tiempo en caso de fallos (potencialmente puede funcionar indefinidamente). Pero en la mayor\u00eda de las situaciones, cuando la mayor\u00eda de los nodos est\u00e1n funcionando correctamente, tendremos progreso en el sistema. <\/p>\n

        En la pr\u00e1ctica, tratamos con modelos de comunicaci\u00f3n parcialmente s\u00edncronos. La parcialidad de la sincronizaci\u00f3n se entiende as\u00ed: en t\u00e9rminos generales, tenemos un modelo as\u00edncrono, pero se introduce formalmente el concepto de \"tiempo de estabilizaci\u00f3n global\" para un momento dado. <\/p>\n

        Este momento puede no llegar durante mucho tiempo, pero tarde o temprano debe llegar. Sonar\u00e1 una alarma virtual y a partir de ese momento podemos predecir la delta de tiempo que tomar\u00e1 llegar los mensajes. A partir de ese momento, el sistema pasa de ser as\u00edncrono a s\u00edncrono. En la pr\u00e1ctica, tratamos precisamente con esos tipos de sistemas. <\/p>\n

        El algoritmo Paxos resuelve problemas de consenso.<\/h2>\n

        \nPaxos <\/a><\/noindex> es un conjunto de algoritmos que resuelven el problema del consenso para sistemas parcialmente s\u00edncronos, bajo la condici\u00f3n de que algunos nodos pueden fallar. El autor de Paxos es Leslie Lamport<\/a><\/noindex>. Propuso una prueba formal de la existencia y correcci\u00f3n del algoritmo en 1989. <\/p>\n

        Sin embargo, la prueba result\u00f3 ser nada trivial. La primera publicaci\u00f3n sali\u00f3 solo en 1998 (33 p\u00e1ginas) describiendo el algoritmo. Result\u00f3 ser extremadamente dif\u00edcil de entender, y en 2001 se public\u00f3 una aclaraci\u00f3n al art\u00edculo que ocup\u00f3 14 p\u00e1ginas. Las extensiones de las publicaciones se proporcionan para demostrar que, en realidad, el problema de consenso no es simple, y detr\u00e1s de dichos algoritmos hay un enorme esfuerzo de las mentes m\u00e1s brillantes.<\/p>\n

        Curiosamente, el mismo Leslie Lamport mencion\u00f3 en su conferencia que en el segundo art\u00edculo de aclaraci\u00f3n hay una afirmaci\u00f3n, una l\u00ednea (no especific\u00f3 cu\u00e1l), que puede ser interpretada de diferentes maneras. Debido a esto, muchas implementaciones modernas de Paxos no funcionan de manera completamente correcta. <\/p><\/blockquote>\n

        \nUn an\u00e1lisis detallado del funcionamiento de Paxos requerir\u00eda m\u00e1s de un art\u00edculo, por lo que intentar\u00e9 transmitir brevemente la idea b\u00e1sica del algoritmo. En los enlaces al final de mi art\u00edculo, encontrar\u00e1 materiales para profundizar en este tema.<\/p>\n

        Roles en Paxos<\/h4>\n

        \nEn el algoritmo Paxos, hay un concepto de roles. Consideremos tres roles principales (hay modificaciones con roles adicionales):<\/p>\n

          \n
        1. Proposers (tambi\u00e9n pueden encontrarse los t\u00e9rminos: l\u00edderes o coordinadores)<\/b>. Estos son chicos que descubren un nuevo valor a partir del usuario y asumen el papel de l\u00edder. Su tarea es iniciar una ronda de propuestas de un nuevo valor y coordinar las acciones posteriores de los nodos. Adem\u00e1s, Paxos permite que haya m\u00faltiples l\u00edderes en determinadas situaciones.<\/li>\n
        2. Aceptores (Votantes)<\/b>. Son nodos que votan a favor o en contra de la aceptaci\u00f3n de un determinado valor. Su papel es muy importante, porque de ellos depende la decisi\u00f3n: a qu\u00e9 estado pasar\u00e1 (o no) el sistema despu\u00e9s de la siguiente etapa del algoritmo de consenso.<\/li>\n
        3. Aprendices<\/b>. Nodos que simplemente reciben y registran el nuevo valor aceptado cuando el estado del sistema cambia. No toman decisiones, solo reciben datos y pueden entregarlos al usuario final. <\/li>\n<\/ol>\n

          \nUn nodo puede combinar varios roles en diferentes situaciones. <\/p>\n

          El concepto de qu\u00f3rum<\/h4>\n

          \nSuponemos que tenemos un sistema de N<\/b> nodos. Y de ellos, como m\u00e1ximo, F<\/b> nodos pueden fallar. Si F nodos fallan, entonces en nuestro cl\u00faster debe haber, como m\u00ednimo, 2F + 1<\/b> nodos acceptor. <\/p>\n

          Esto es necesario para que siempre, incluso en la peor situaci\u00f3n, los nodos 'buenos', que funcionan correctamente, tengan la mayor\u00eda. Es decir, F + 1<\/b> nodos 'buenos' que hayan coincidido, y el valor final ser\u00e1 aceptado. De lo contrario, podr\u00eda haber una situaci\u00f3n en la que diferentes grupos locales adopten valores diferentes y no puedan llegar a un acuerdo entre s\u00ed. Por lo tanto, necesitamos una mayor\u00eda absoluta para ganar en la votaci\u00f3n.<\/p>\n

          La idea general del funcionamiento del algoritmo de consenso Paxos<\/h4>\n

          \nEl algoritmo Paxos implica dos grandes fases, las cuales se dividen en dos pasos cada una:<\/p>\n

            \n
          1. Fase 1a: Preparar<\/b>. En la etapa de preparaci\u00f3n, el l\u00edder (proposer) informa a todos los nodos: \u00abComenzamos una nueva fase de votaci\u00f3n. Tenemos una nueva ronda. El n\u00famero de esta ronda es n. Ahora comenzaremos a votar\u00bb. Por ahora, solo comunica el inicio de un nuevo ciclo, pero no revela un nuevo valor. La tarea de esta etapa es iniciar una nueva ronda y comunicar a todos su n\u00famero \u00fanico. El n\u00famero de ronda es importante; debe ser un valor mayor que todos los n\u00fameros de votaciones anteriores de todos los l\u00edderes anteriores. Esto se debe a que, gracias al n\u00famero de ronda, otros nodos en el sistema comprender\u00e1n cu\u00e1n recientes son los datos del l\u00edder. Probablemente, otros nodos ya tienen resultados de votaciones de rondas mucho m\u00e1s recientes y simplemente le dir\u00e1n al l\u00edder que est\u00e1 desactualizado.<\/li>\n
          2. Fase 1b: Promesa<\/b>. Cuando los nodos acceptor reciben el n\u00famero de la nueva fase de votaci\u00f3n, pueden ocurrir dos resultados: \n