{"id":52525,"date":"2019-11-10T00:00:00","date_gmt":"2019-11-09T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah"},"modified":"2020-02-18T14:00:16","modified_gmt":"2020-02-18T11:00:16","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa tolerancia a fallos y la alta disponibilidad son temas amplios, as\u00ed que dedicaremos art\u00edculos separados a RabbitMQ y Kafka. Este art\u00edculo trata sobre RabbitMQ, y el siguiente ser\u00e1 sobre Kafka, en comparaci\u00f3n con RabbitMQ. El art\u00edculo es extenso, as\u00ed que acom\u00f3dense.<\/p>\n<p>Analizaremos las estrategias de tolerancia a fallos, consistencia y alta disponibilidad (HA), as\u00ed como los compromisos que hay que asumir en cada estrategia. RabbitMQ puede funcionar en un cl\u00faster de nodos, lo que lo clasifica como un sistema distribuido. Cuando hablamos de sistemas distribuidos, frecuentemente nos referimos a consistencia y disponibilidad. <\/p>\n<p>Estos conceptos describen c\u00f3mo se comporta un sistema ante fallos. La falla de una conexi\u00f3n de red, un servidor, un disco duro, la inaccesibilidad temporal de un servidor debido a la recolecci\u00f3n de basura, la p\u00e9rdida de paquetes o la ralentizaci\u00f3n de la conexi\u00f3n de red. Todo esto puede llevar a la p\u00e9rdida de datos o a conflictos. Resulta que es pr\u00e1cticamente imposible tener un sistema que sea completamente consistente (sin p\u00e9rdida de datos ni discrepancias) y disponible (que acepte operaciones de lectura y escritura) para todos los tipos de fallos.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nVeremos que la consistencia y la disponibilidad est\u00e1n en extremos opuestos del espectro, y se debe elegir en qu\u00e9 direcci\u00f3n optimizar. La buena noticia es que con RabbitMQ esta elecci\u00f3n es posible. Tienes esos peque\u00f1os \"interruptores de nerd\" para mover el equilibrio hacia una mayor consistencia o una mayor disponibilidad.<\/p>\n<p>Prestaremos especial atenci\u00f3n a las configuraciones que conducen a la p\u00e9rdida de datos debido a confirmaciones de registro. Hay una cadena de responsabilidad entre publicadores, corredores y consumidores. Despu\u00e9s de que un mensaje se env\u00eda al corredor, es su trabajo no perder el mensaje. Cuando el corredor confirma al publicador que ha recibido el mensaje, no esperamos que se pierda. Pero veremos que esto puede ocurrir realmente dependiendo de la configuraci\u00f3n de tu corredor y publicador.<\/p>\n<h1>Primitivos de resistencia de un solo nodo<\/h1>\n<p><\/p>\n<h3>Colas resistentes\/ruteo<\/h3>\n<p>\nEn RabbitMQ hay dos tipos de colas: duraderas (durable) y no duraderas (non-durable). Todas las colas se almacenan en la base de datos Mnesia. Las colas duraderas se vuelven a declarar al iniciar el nodo y, de esta manera, sobreviven a un reinicio, una falla del sistema o una ca\u00edda del servidor (mientras se conserven los datos). Esto significa que siempre que declares la ruta (exchange) y la cola como duraderas, la infraestructura de colas\/rutas volver\u00e1 a funcionar.<\/p>\n<p>Las colas y rutas no duraderas se eliminan al reiniciar el nodo.<\/p>\n<h3>Mensajes duraderos<\/h3>\n<p>\nEl hecho de que una cola sea duradera no significa que todos sus mensajes sobrevivan al reinicio del nodo. Solo se recuperar\u00e1n los mensajes marcados por el publicador como <i>duraderos<\/i> (persistent). Los mensajes duraderos realmente generan una carga adicional en el broker, pero si la p\u00e9rdida de un mensaje no es aceptable, no hay otra salida.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 1. Matriz de durabilidad<\/i><\/p>\n<h1>Clustering con replicaci\u00f3n de colas<\/h1>\n<p>\nPara sobrevivir a la p\u00e9rdida de un broker, necesitamos redundancia. Podemos unir varios nodos de RabbitMQ en un cl\u00faster y luego a\u00f1adir redundancia adicional replicando las colas entre varios nodos. De esta forma, si un nodo falla, no perdemos datos y seguimos disponibles. <\/p>\n<p>Replicaci\u00f3n de colas:<\/p>\n<ul>\n<li>una cola principal (master), que recibe todos los comandos de escritura y lectura\n<\/li>\n<li>uno o m\u00e1s espejos, que reciben todos los mensajes y metadatos de la cola principal. Estos espejos no existen para escalar, sino exclusivamente para redundancia.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 2. Replicaci\u00f3n de colas<\/i><\/p>\n<p>La replicaci\u00f3n se establece mediante una pol\u00edtica correspondiente. En ella se puede elegir el coeficiente de replicaci\u00f3n e incluso los nodos en los que debe residir la cola. Ejemplos:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (un maestro y un espejo)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Confirmaci\u00f3n al publicador<\/h1>\n<p>\nPara lograr una grabaci\u00f3n coherente, se requieren confirmaciones del publicador (Publisher Confirms). Sin ellas, existe la posibilidad de p\u00e9rdida de mensajes. La confirmaci\u00f3n se env\u00eda al publicador despu\u00e9s de que se grabe el mensaje en el disco. RabbitMQ graba mensajes en el disco no al recibirlos, sino de manera peri\u00f3dica, en el orden de varios cientos de milisegundos. Cuando se espejan colas, la confirmaci\u00f3n se env\u00eda solo despu\u00e9s de que todos los espejos tambi\u00e9n hayan grabado su copia del mensaje en el disco. Esto significa que el uso de confirmaciones agrega un retraso, pero si la seguridad de los datos es importante, son necesarias.<\/p>\n<h1>Cola tolerante a fallos<\/h1>\n<p>\nCuando el corredor se apaga o falla, todas las colas principales (m\u00e1ster) en este nodo se desconectan junto con \u00e9l. Luego, el cl\u00faster elige el espejo m\u00e1s antiguo de cada m\u00e1ster y lo promueve como nuevo m\u00e1ster.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 3. Varias colas espejadas y sus pol\u00edticas<\/i><\/p>\n<p>El corredor 3 falla. Nota que el espejo de la Cola C en el Corredor 2 se eleva a m\u00e1ster. Tambi\u00e9n se observa que se ha creado un nuevo espejo para la Cola C en el Corredor 1. RabbitMQ siempre intenta mantener la tasa de replicaci\u00f3n indicada en sus pol\u00edticas.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 4. El corredor 3 falla, lo que causa el fallo de la cola C<\/i> <\/p>\n<p>\u00a1Falla el siguiente Corredor 1! Solo nos queda un corredor. El espejo de la Cola B se eleva a m\u00e1ster.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 5<\/i><\/p>\n<p>Hemos recuperado el Corredor 1. Independientemente de cu\u00e1n exitosamente los datos sobrevivieron a la p\u00e9rdida y recuperaci\u00f3n del corredor, todos los mensajes espejados de la cola se descartan al reiniciarse. Esto es importante se\u00f1alar, ya que habr\u00e1 consecuencias. Pronto revisaremos estas consecuencias. As\u00ed, el Corredor 1 ahora vuelve a ser miembro del cl\u00faster, y el cl\u00faster intenta cumplir con las pol\u00edticas y, por lo tanto, crea espejos en el Corredor 1.<\/p>\n<p>En este caso, la p\u00e9rdida del Corredor 1 fue total, al igual que los datos, por lo que la Cola B no espejada se perdi\u00f3 completamente.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 6. El Corredor 1 vuelve a estar en funcionamiento<\/i><\/p>\n<p>El Broker 3 ha vuelto a estar operativo, lo que permite que las colas A y B recuperen los espejos creados en \u00e9l para satisfacer sus pol\u00edticas de HA. Pero ahora todas las colas principales est\u00e1n en un solo nodo. \u00a1Esto no es ideal, es mejor tener una distribuci\u00f3n uniforme entre nodos! Desafortunadamente, no hay muchas opciones aqu\u00ed para reequilibrar los maestros. Volveremos a este problema m\u00e1s tarde, ya que primero debemos considerar la sincronizaci\u00f3n de la cola. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 7. El Broker 3 vuelve a estar operativo. \u00a1Todas las colas principales en un solo nodo!<\/i><\/p>\n<p>As\u00ed que ahora deber\u00edan tener una idea de c\u00f3mo los espejos proporcionan redundancia y alta disponibilidad. Esto garantiza la accesibilidad en caso de falla de un nodo y protege contra la p\u00e9rdida de datos. Pero a\u00fan no hemos terminado, porque en realidad es mucho m\u00e1s complicado.<\/p>\n<h1>Sincronizaci\u00f3n<\/h1>\n<p>\nAl crear un nuevo espejo, todos los nuevos mensajes siempre se replicar\u00e1n en este espejo y en cualquier otro. En cuanto a los datos existentes en la cola principal, podemos replicarlos en el nuevo espejo, que se convierte en una copia completa del maestro. Tambi\u00e9n podemos optar por no replicar los mensajes existentes y permitir que la cola principal y el nuevo espejo se sincronicen con el tiempo, a medida que los nuevos mensajes llegan al final y los mensajes existentes salen del principio de la cola principal.<\/p>\n<p>Esta sincronizaci\u00f3n se lleva a cabo autom\u00e1ticamente o manualmente y se gestiona mediante pol\u00edticas de cola. Veamos un ejemplo.<\/p>\n<p>Tenemos dos colas espejadas. La Cola A se sincroniza autom\u00e1ticamente, mientras que la Cola B se sincroniza manualmente. Ambas colas tienen diez mensajes.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 8. Dos colas con diferentes modos de sincronizaci\u00f3n.<\/i><\/p>\n<p>Ahora estamos perdiendo el Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 9. El Broker 3 ha ca\u00eddo.<\/i><\/p>\n<p>El Broker 3 vuelve a estar operativo. El cl\u00faster crea un espejo para cada cola en un nuevo nodo y sincroniza autom\u00e1ticamente la nueva Cola A con el maestro. Sin embargo, el espejo de la nueva Cola B permanece vac\u00edo. Por lo tanto, tenemos una redundancia completa para la Cola A y solo un espejo para los mensajes existentes de la Cola B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 10. El nuevo espejo de la Cola A recibe todos los mensajes existentes, mientras que el nuevo espejo de la Cola B no.<\/i><\/p>\n<p>En ambas colas llegan otros diez mensajes. Luego, el Broker 2 se cae, y la Cola A retrocede al espejo m\u00e1s antiguo que se encuentra en el Broker 1. No hay p\u00e9rdida de datos durante la falla. En la Cola B hay veinte mensajes en el maestro y solo diez en el espejo, ya que esta cola nunca replic\u00f3 los diez mensajes originales.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 11. La Cola A retrocede en el Broker 1 sin p\u00e9rdida de mensajes<\/i><\/p>\n<p>En ambas colas llegan otros diez mensajes. Ahora, se cae el Broker 1. La Cola A se cambia al espejo sin p\u00e9rdida de mensajes. Sin embargo, la Cola B tiene problemas. En esta etapa, podemos optimizar ya sea la disponibilidad o la consistencia. <\/p>\n<p>Si queremos optimizar la disponibilidad, entonces la pol\u00edtica <b><i>ha-promote-on-failure<\/i><\/b> deber\u00eda establecerse en <b><i>always<\/i><\/b>. Este es el valor predeterminado, as\u00ed que simplemente podemos no especificar la pol\u00edtica en absoluto. En este caso, de hecho, permitimos fallas en los espejos no sincronizados. Esto conducir\u00e1 a la p\u00e9rdida de mensajes, pero la cola seguir\u00e1 siendo accesible para lectura y escritura.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 12. La Cola A retrocede al Broker 3 sin p\u00e9rdida de mensajes. La Cola B retrocede al Broker 3 con p\u00e9rdida de diez mensajes<\/i><\/p>\n<p>Tambi\u00e9n podemos establecer <code>ha-promote-on-failure<\/code> en <code>when-synced<\/code>. En este caso, en lugar de retroceder al espejo, la cola esperar\u00e1 hasta que el Broker 1 regrese a modo operativo con sus datos. Tras su regreso, la cola principal vuelve a estar en el Broker 1 sin p\u00e9rdida de datos. La disponibilidad se sacrifica a la seguridad de los datos. Pero este es un modo arriesgado que puede incluso llevar a la p\u00e9rdida total de datos, lo que discutiremos pronto.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 13. La Cola B sigue siendo inaccesible despu\u00e9s de la p\u00e9rdida del Broker 1<\/i><\/p>\n<p>Puedes preguntarte: \"\u00bfQuiz\u00e1s sea mejor nunca usar la sincronizaci\u00f3n autom\u00e1tica?\". La respuesta es que la sincronizaci\u00f3n es una operaci\u00f3n bloqueante. \u00a1Durante la sincronizaci\u00f3n, la cola principal no puede realizar operaciones de lectura o escritura!<\/p>\n<p>Consideremos un ejemplo. Ahora tenemos colas muy grandes. \u00bfC\u00f3mo pueden crecer a tal tama\u00f1o? Por varias razones:<\/p>\n<ul>\n<li>Las colas no se utilizan activamente\n<\/li>\n<li>Son colas de alta velocidad, y en este momento los consumidores est\u00e1n funcionando lentamente \n<\/li>\n<li>Son colas de alta velocidad, ha habido una falla, y los consumidores est\u00e1n recuper\u00e1ndose<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 14. Dos grandes colas con diferentes modos de sincronizaci\u00f3n<\/i><\/p>\n<p>Ahora falla el Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 15. El Broker 3 falla, dejando un maestro y un espejo en cada cola<\/i><\/p>\n<p>El Broker 3 vuelve a estar operativo y se crean nuevos espejos. La Cola Principal A comienza a replicar los mensajes existentes en el nuevo espejo, y durante este tiempo la Cola no est\u00e1 disponible. La replicaci\u00f3n de datos tarda dos horas, lo que resulta en dos horas de inactividad para esta Cola.<\/p>\n<p>Sin embargo, la Cola B permanece disponible durante todo el per\u00edodo. Sacrific\u00f3 cierta redundancia a favor de la disponibilidad.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 16. La cola permanece sin disponibilidad durante la sincronizaci\u00f3n<\/i><\/p>\n<p>Despu\u00e9s de dos horas, la Cola A tambi\u00e9n se vuelve disponible y puede comenzar a aceptar operaciones de lectura y escritura nuevamente.<\/p>\n<h3>Actualizaciones<\/h3>\n<p>\nEste comportamiento bloqueante durante la sincronizaci\u00f3n dificulta la actualizaci\u00f3n de cl\u00fasteres con colas muy grandes. En alg\u00fan momento, es necesario reiniciar el nodo con el maestro, lo que significa pasar a un espejo o desactivar la cola durante la actualizaci\u00f3n del servidor. Si elegimos el paso, perderemos mensajes si los espejos no est\u00e1n sincronizados. Por defecto, durante la desconexi\u00f3n del broker, no se realiza la transici\u00f3n a un espejo no sincronizado. Esto significa que, una vez que el broker vuelve, no perdemos ning\u00fan mensaje, siendo la \u00fanica p\u00e9rdida el tiempo de inactividad de la cola. Las reglas de comportamiento al desconectar el broker son establecidas por la pol\u00edtica <code>ha-promote-on-shutdown<\/code>. Se puede establecer uno de dos valores:<\/p>\n<ul>\n<li><code>always<\/code>= se activa el paso a espejos no sincronizados\n<\/li>\n<li><code>when-synced<\/code>= se pasa solamente a un espejo sincronizado, de lo contrario la cola se vuelve inaccesible para lectura y escritura. La cola vuelve a estar operativa tan pronto como regresa el broker<\/li>\n<\/ul>\n<p>\nDe una forma u otra, con colas grandes hay que elegir entre perder datos y la inaccesibilidad.<\/p>\n<h3>Cuando la disponibilidad aumenta la seguridad de los datos<\/h3>\n<p>\nAntes de tomar una decisi\u00f3n, es necesario considerar otra complicaci\u00f3n. Aunque la sincronizaci\u00f3n autom\u00e1tica es mejor para la redundancia, \u00bfc\u00f3mo afecta esto a la seguridad de los datos? Ciertamente, gracias a una mejor redundancia, RabbitMQ tiene menos probabilidades de perder mensajes existentes, pero \u00bfqu\u00e9 pasa con los nuevos mensajes de los publicadores?<\/p>\n<p>Aqu\u00ed se debe considerar lo siguiente:<\/p>\n<ul>\n<li>\u00bfPuede el publicador simplemente devolver un error y el servicio superior o el usuario intentar de nuevo m\u00e1s tarde?\n<\/li>\n<li>\u00bfPuede el publicador guardar el mensaje localmente o en una base de datos para volver a intentarlo m\u00e1s tarde?<\/li>\n<\/ul>\n<p>\nSi el publicador solo puede descartar el mensaje, entonces, de hecho, mejorar la disponibilidad tambi\u00e9n aumenta la seguridad de los datos.<\/p>\n<p>Por lo tanto, se debe buscar un equilibrio y la soluci\u00f3n depende de la situaci\u00f3n concreta.<\/p>\n<h1>Problemas con ha-promote-on-failure=when-synced<\/h1>\n<p>\nLa idea <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> es que evitamos cambiar a un espejo no sincronizado y, por lo tanto, evitamos la p\u00e9rdida de datos. La cola permanece inaccesible para lectura o escritura. En lugar de eso, intentamos recuperar el corredor ca\u00eddo con datos intactos para que reanude su funci\u00f3n como maestro sin p\u00e9rdida de datos. <\/p>\n<p>Pero (y esto es un gran pero) si el corredor ha perdido sus datos, entonces tenemos un gran problema: \u00a1la cola se ha perdido! \u00a1Todos los datos se han ido! Incluso si tienes espejos que principalmente alcanzan la cola principal, esos espejos tambi\u00e9n se descartan.<\/p>\n<p>Para volver a a\u00f1adir un nodo con el mismo nombre, le decimos al cl\u00faster que olvide el nodo perdido (con el comando <i>rabbitmqctl forget_cluster_node<\/i>) y empezamos un nuevo corredor con el mismo nombre de host. Mientras el cl\u00faster recuerde el nodo perdido, tambi\u00e9n recordar\u00e1 la vieja cola y los espejos no sincronizados. Cuando se le dice al cl\u00faster que olvide el nodo perdido, esa cola tambi\u00e9n se olvida. Ahora es necesario volver a declararla. Hemos perdido todos los datos, aunque ten\u00edamos espejos con un conjunto de datos parcial. \u00a1Hubiera sido mejor cambiar a un espejo no sincronizado!<\/p>\n<p>Por lo tanto, la sincronizaci\u00f3n manual (y la falta de sincronizaci\u00f3n) junto con <code>ha-promote-on-failure=when-synced<\/code>, en mi opini\u00f3n, es bastante arriesgada. La documentaci\u00f3n dice que tal opci\u00f3n existe para la seguridad de los datos, pero es un arma de doble filo.<\/p>\n<h1>Rebalanceo de maestros<\/h1>\n<p>\nComo se prometi\u00f3, volvemos al problema de que todos los maestros se acumulen en uno o varios nodos. Esto puede suceder incluso como resultado de una actualizaci\u00f3n 'deslizante' (rolling) del cl\u00faster. En un cl\u00faster con tres nodos, todas las colas principales se acumular\u00e1n en uno o dos nodos.<\/p>\n<p>El rebalanceo de maestros puede ser problem\u00e1tico por dos razones:<\/p>\n<ul>\n<li>No hay buenas herramientas para realizar el rebalanceo<\/li>\n<li>Sincronizaci\u00f3n de colas<\/li>\n<\/ul>\n<p>\nHay un complemento de terceros <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, que no es oficialmente soportado. En la documentaci\u00f3n de RabbitMQ se menciona sobre los complementos de terceros <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">que dice<\/a><\/noindex>: \u00abEl complemento proporciona algunas herramientas adicionales para la configuraci\u00f3n y reportes, pero no es soportado ni verificado por el equipo de RabbitMQ. \u00daselo bajo su propio riesgo\u00bb.<\/p>\n<p>Hay otro truco para mover la cola principal a trav\u00e9s de pol\u00edticas de HA. En la documentaci\u00f3n se menciona un <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">script<\/a><\/noindex> para esto. Funciona de la siguiente manera:<\/p>\n<ul>\n<li>Elimina todos los espejos con una pol\u00edtica temporal de mayor prioridad que la pol\u00edtica de HA existente.\n<\/li>\n<li>Cambia la pol\u00edtica temporal de HA para usar el modo 'nodos' especificando el nodo al que se debe mover la cola principal.\n<\/li>\n<li>Sincroniza la cola para forzar la migraci\u00f3n.\n<\/li>\n<li>Una vez finalizada la migraci\u00f3n, elimina la pol\u00edtica temporal. Se activa la pol\u00edtica de HA original y se crea el n\u00famero necesario de espejos.<\/li>\n<\/ul>\n<p>\nLa desventaja es que este enfoque puede no funcionar si tiene colas grandes o estrictos requisitos de redundancia.<\/p>\n<p>Ahora veamos c\u00f3mo funcionan los cl\u00fasteres de RabbitMQ con particiones de red.<\/p>\n<h1>Violaci\u00f3n de la coherencia<\/h1>\n<p>\nLos nodos de un sistema distribuido est\u00e1n conectados por enlaces de red, y los enlaces de red pueden y se desconectar\u00e1n. La frecuencia de las desconexiones depende de la infraestructura local o de la fiabilidad de la nube elegida. En cualquier caso, los sistemas distribuidos deben ser capaces de manejar estas situaciones. Nuevamente, nos enfrentamos a la elecci\u00f3n entre disponibilidad y coherencia, y una vez m\u00e1s, la buena noticia es que RabbitMQ proporciona ambas opciones (simplemente no al mismo tiempo).<\/p>\n<p>Con RabbitMQ tenemos dos opciones principales:<\/p>\n<ul>\n<li>Permitir la divisi\u00f3n l\u00f3gica (split-brain). Esto garantiza la disponibilidad, pero puede provocar p\u00e9rdida de datos.\n<\/li>\n<li>Prohibir la divisi\u00f3n l\u00f3gica. Esto puede resultar en una p\u00e9rdida temporal de disponibilidad dependiendo de c\u00f3mo los clientes se conecten al cl\u00faster. Tambi\u00e9n puede llevar a una falta total de disponibilidad en un cl\u00faster de dos nodos.<\/li>\n<\/ul>\n<p>\n\u00bfPero qu\u00e9 es la divisi\u00f3n l\u00f3gica? Es cuando un cl\u00faster se divide en dos debido a la p\u00e9rdida de enlaces de red. En cada lado, los espejos se elevan a maestro, de modo que al final hay varios maestros para cada cola.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 17. Cola principal y dos espejos, cada uno en un nodo separado. Luego ocurre una falla en la red, y un espejo se separa. El nodo separado ve que los otros dos han ca\u00eddo, y promueve sus espejos a maestro. Ahora tenemos dos colas principales, y ambas permiten lectura y escritura.<\/i> <\/p>\n<p>Si los editores env\u00edan datos a ambos maestros, tendremos dos copias divergentes de la cola.<\/p>\n<p>Los diferentes modos de RabbitMQ garantizan ya sea disponibilidad o consistencia.<\/p>\n<h3>Modo Ignorar (por defecto)<\/h3>\n<p>\nEste modo asegura disponibilidad. Despu\u00e9s de perder la conectividad, ocurre una separaci\u00f3n l\u00f3gica. Tras la recuperaci\u00f3n de la conectividad, el administrador debe decidir a qu\u00e9 secci\u00f3n dar preferencia. El lado perdedor se reiniciar\u00e1, y todos los datos acumulados en ese lado se perder\u00e1n.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 18. Tres editores est\u00e1n conectados a tres brokers. Internamente, el cl\u00faster dirige todas las solicitudes a la cola principal en el Broker 2.<\/i><\/p>\n<p>Ahora estamos perdiendo el Broker 3. \u00c9l ve que otros brokers han ca\u00eddo y promueve su espejo a maestro. As\u00ed es como ocurre la separaci\u00f3n l\u00f3gica.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 19. Separaci\u00f3n l\u00f3gica (split-brain). Las escrituras van a dos colas principales, y las dos copias se divergen.<\/i><\/p>\n<p>La conectividad se restaura, pero la separaci\u00f3n l\u00f3gica permanece. El administrador debe seleccionar manualmente el lado perdedor. En el caso siguiente, el administrador reinicia el Broker 3. Se pierden todos los mensajes que no se hab\u00edan enviado.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 20. El administrador desconecta el Broker 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 21. El administrador inicia el Broker 3 y se une al cl\u00faster, perdiendo todos los mensajes que all\u00ed hab\u00edan quedado.<\/i><\/p>\n<p>Durante la p\u00e9rdida de conectividad y despu\u00e9s de su recuperaci\u00f3n, el cl\u00faster y esta cola estuvieron disponibles para lectura y escritura.<\/p>\n<h3>Modo Autoheal<\/h3>\n<p>\nFunciona de manera similar al modo Ignorar, con la excepci\u00f3n de que el cl\u00faster autom\u00e1ticamente elige el lado perdedor despu\u00e9s de la separaci\u00f3n y restauraci\u00f3n de la conectividad. El lado perdedor vuelve al cl\u00faster vac\u00edo, y la cola pierde todos los mensajes que se enviaron solo a ese lado.<\/p>\n<h3>Modo Pausar Minor\u00eda<\/h3>\n<p>\nSi no queremos permitir la divisi\u00f3n l\u00f3gica, nuestra \u00fanica opci\u00f3n es renunciar a la lectura y escritura en el lado menor despu\u00e9s de la partici\u00f3n del cl\u00faster. Cuando el corredor ve que est\u00e1 en el lado menor, suspende su funcionamiento, es decir, cierra todas las conexiones existentes y rechaza cualquier nueva. Una vez por segundo, comprueba la recuperaci\u00f3n de la conectividad. Tan pronto como la conectividad se restablece, reanuda su funcionamiento y se une al cl\u00faster.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 22. Tres editores est\u00e1n conectados a tres corredores. Internamente, el cl\u00faster dirige todas las solicitudes a la cola principal del Corredor 2.<\/i><\/p>\n<p>Luego, los Corredores 1 y 2 se separan del Corredor 3. En lugar de elevar su espejo a maestro, el Corredor 3 suspende su funcionamiento y se vuelve inaccesible.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 23. El Corredor 3 suspende su funcionamiento, desconecta a todos los clientes y rechaza las solicitudes de conexi\u00f3n.<\/i><\/p>\n<p>Una vez que se restablece la conectividad, regresa al cl\u00faster.<\/p>\n<p>Veamos otro ejemplo, donde la cola principal est\u00e1 en el Corredor 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 24. Cola principal en el Corredor 3.<\/i><\/p>\n<p>Luego ocurre la misma p\u00e9rdida de conectividad. El Corredor 3 se pone en pausa, ya que est\u00e1 en el lado menor. En el otro lado, los nodos ven que el Corredor 3 ha fallado, as\u00ed que un espejo m\u00e1s antiguo de los Corredores 1 y 2 se eleva a maestro.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 25. Transici\u00f3n al Corredor 2 en la falta de disponibilidad del Corredor 3.<\/i><\/p>\n<p>Cuando se restablece la conectividad, el Corredor 3 se unir\u00e1 al cl\u00faster.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ frente a Kafka: tolerancia a fallos y alta disponibilidad en cl\u00fasteres\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 26. El cl\u00faster ha vuelto a su funcionamiento normal.<\/i><\/p>\n<p>Aqu\u00ed es importante entender que obtenemos consistencia, pero tambi\u00e9n podemos obtener disponibilidad, <i><b>si<\/b><\/i> logramos trasladar a los clientes a la parte mayor de la partici\u00f3n. Para la mayor\u00eda de las situaciones, personalmente elegir\u00eda el modo Pause Minority, pero realmente depende del caso concreto.<\/p>\n<p>Para garantizar la disponibilidad, es importante asegurarse de que los clientes se conecten con \u00e9xito al nodo. Veamos nuestras opciones.<\/p>\n<h1>Garantizando la conectividad de los clientes<\/h1>\n<p>\nTenemos varias opciones sobre c\u00f3mo redirigir a los clientes a la parte principal del cl\u00faster o a los nodos en funcionamiento despu\u00e9s de una p\u00e9rdida de conectividad (tras el fallo de un nodo). Primero recordemos que una cola espec\u00edfica se ubica en un nodo determinado, pero el enrutamiento y las pol\u00edticas se replican en todos los nodos. Los clientes pueden conectarse a cualquier nodo y el enrutamiento interno los dirigir\u00e1 donde sea necesario. Sin embargo, cuando un nodo est\u00e1 detenido, rechaza las conexiones, por lo que los clientes deben conectarse a otro nodo. Si un nodo falla, tiene muy poco que ofrecer.<\/p>\n<p>Nuestras opciones:<\/p>\n<ul>\n<li>El acceso al cl\u00faster se realiza a trav\u00e9s de un balanceador de carga que simplemente recorre c\u00edclicamente los nodos, mientras que los clientes intentan reconectar hasta lograrlo. Si un nodo no est\u00e1 funcionando o est\u00e1 detenido, los intentos de conexi\u00f3n a este nodo fallar\u00e1n, pero los intentos posteriores ir\u00e1n a otros servidores (en modo c\u00edclico). Esto es adecuado para una p\u00e9rdida temporal de conectividad o un servidor ca\u00eddo que se levantar\u00e1 r\u00e1pidamente.\n<\/li>\n<li>Acceso al cl\u00faster a trav\u00e9s de un balanceador de carga y eliminar nodos detenidos\/ca\u00eddos de la lista tan pronto como sean detectados. Si esto se hace r\u00e1pidamente, y si los clientes pueden intentar reconectar, obtendremos disponibilidad continua.\n<\/li>\n<li>Dar a cada cliente una lista de todos los nodos, y el cliente al conectarse elige aleatoriamente uno de ellos. Si al intentar conectarse recibe un error, pasa al siguiente nodo de la lista hasta que se conecte.\n<\/li>\n<li>Eliminar el tr\u00e1fico del nodo ca\u00eddo\/detenido mediante DNS. Esto se hace usando un TTL bajo.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Conclusiones<\/h1>\n<p>\nLa agrupaci\u00f3n de RabbitMQ tiene sus ventajas y desventajas. Las desventajas m\u00e1s serias son que:<\/p>\n<ul>\n<li>al unirse al cl\u00faster, los nodos descartan sus datos;\n<\/li>\n<li>la sincronizaci\u00f3n bloqueante lleva a la inaccesibilidad de la cola.<\/li>\n<\/ul>\n<p>\nTodas las decisiones dif\u00edciles surgen de estas dos caracter\u00edsticas de la arquitectura. Si RabbitMQ pudiera almacenar datos al reconectar el cl\u00faster, la sincronizaci\u00f3n ser\u00eda m\u00e1s r\u00e1pida. Si pudiera realizar sincronizaci\u00f3n no bloqueante, manejar\u00eda mejor colas grandes. Abordar estos dos problemas mejorar\u00eda significativamente las caracter\u00edsticas de RabbitMQ como tecnolog\u00eda de mensajer\u00eda resistente y de alta disponibilidad. No me atrever\u00eda a recomendar RabbitMQ con clustering en las siguientes situaciones:<\/p>\n<ul>\n<li>Red poco fiable.\n<\/li>\n<li>Almacenamiento poco fiable.\n<\/li>\n<li>Colas muy grandes.<\/li>\n<\/ul>\n<p>\nEn cuanto a las configuraciones para alta disponibilidad, considere las siguientes:<\/p>\n<ul>\n<li><code>ha-promote-on-failure=always<\/code>\n<\/li>\n<li><code>ha-sync-mode=manual<\/code>\n<\/li>\n<li><code>cluster_partition_handling=ignore<\/code> (o <code>autoheal<\/code>)\n<\/li>\n<li>mensajes persistentes\n<\/li>\n<li>aseg\u00farese de que los clientes se conecten al nodo activo cuando alg\u00fan nodo falle<\/li>\n<\/ul>\n<p>\nPara consistencia (seguridad de datos), considere las siguientes configuraciones:<\/p>\n<ul>\n<li>Publisher Confirms y Acknowledgements Manuales del lado del consumidor\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, si los editores pueden reintentar m\u00e1s tarde y si tiene un almacenamiento muy fiable. \u00a1De lo contrario, configure <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (pero para colas inactivas grandes puede ser necesario el modo manual; adem\u00e1s, considere si la indisponibilidad puede conducir a la p\u00e9rdida de mensajes)\n<\/li>\n<li>modo Pause Minority\n<\/li>\n<li>mensajes persistentes<\/li>\n<\/ul>\n<p>\nA\u00fan no hemos cubierto todos los temas de resiliencia y alta disponibilidad; por ejemplo, c\u00f3mo realizar procedimientos administrativos de manera segura (como actualizaciones deslizantes). Tambi\u00e9n hay que hablar sobre la federaci\u00f3n y el plugin Shovel.<\/p>\n<p>Si he pasado por alto algo, por favor h\u00e1ganmelo saber.<\/p>\n<p>Consulte tambi\u00e9n mi <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">publicaci\u00f3n<\/a><\/noindex>, donde realizo una revisi\u00f3n del cl\u00faster RabbitMQ utilizando Docker y Blockade para probar algunos escenarios de p\u00e9rdida de mensajes, como se describe en este art\u00edculo.<\/p>\n<p>Art\u00edculos anteriores de la serie: <br \/>\n#1 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/416629\/\">habr.com\/es\/company\/itsumma\/blog\/416629<\/a><\/noindex> <br \/>\n#2 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/418389\/\">habr.com\/es\/company\/itsumma\/blog\/418389<\/a><\/noindex> <br \/>\n#3 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/437446\/\">habr.com\/es\/company\/itsumma\/blog\/437446<\/a><\/noindex><br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u2014 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0442\u0435\u043c\u044b, \u0442\u0430\u043a \u0447\u0442\u043e \u043f\u043e\u0441\u0432\u044f\u0442\u0438\u043c RabbitMQ \u0438 Kafka \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0441\u0442\u0430\u0442\u044c\u0438. \u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043e RabbitMQ, \u0430 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u2014 \u043e Kafka, \u0432 \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u0438 \u0441 RabbitMQ. \u0421\u0442\u0430\u0442\u044c\u044f \u0434\u043b\u0438\u043d\u043d\u0430\u044f, \u0442\u0430\u043a \u0447\u0442\u043e \u0443\u0441\u0442\u0440\u0430\u0438\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043f\u043e\u0443\u0434\u043e\u0431\u043d\u0435\u0435. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438, \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u0438 (HA), \u0430 \u0442\u0430\u043a\u0436\u0435 \u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0438\u0441\u0441\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0438\u0434\u0442\u0438 \u0432 \u043a\u0430\u0436\u0434\u043e\u0439 \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438. RabbitMQ \u043c\u043e\u0436\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52525","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\".\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\".\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-09T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47RabbitMQ vs Kafka: resiliencia y alta disponibilidad en cl\u00fasteres | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-09T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52525","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 03:54:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:41:25","updated":"2026-01-24 03:54:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/52525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}