{"id":52541,"date":"2019-11-11T00:00:00","date_gmt":"2019-11-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost"},"modified":"2020-02-18T14:00:17","modified_gmt":"2020-02-18T11:00:17","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","title":{"rendered":"RabbitMQ contro Kafka: resilienza e alta disponibilit\u00e0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"RabbitMQ
\n
\nIn un articolo precedente<\/a><\/noindex> Abbiamo esaminato la clusterizzazione di RabbitMQ per garantire la resilienza e l'alta disponibilit\u00e0. Ora approfondiamo Apache Kafka.<\/p>\n

In questo contesto, l'unit\u00e0 di replica \u00e8 la partizione. Ogni argomento ha una o pi\u00f9 partizioni. In ogni partizione c'\u00e8 un leader con o senza follower. Quando si crea un argomento, si specifica il numero di partizioni e il fattore di replica. Il valore tipico \u00e8 3, il che significa tre repliche: un leader e due follower.
\n<\/a><\/noindex><\/p>\n

\"RabbitMQ
\nFig. 1. Quattro partizioni distribuite tra tre broker<\/i><\/p>\n

Tutte le richieste di lettura e scrittura vengono inviate al leader. I follower inviano periodicamente richieste al leader per ottenere gli ultimi messaggi. I consumatori non si collegano mai ai follower; questi ultimi esistono solo per ridondanza e resilienza.<\/p>\n

\"RabbitMQ
\n<\/p>\n

Guasto della partizione<\/h1>\n

\nQuando un broker cade, spesso i leader di diverse partizioni smettono di funzionare. In ognuna di esse, un follower di un altro nodo diventa il nuovo leader. In realt\u00e0, ci\u00f2 non avviene sempre, poich\u00e9 influisce anche il fattore di sincronizzazione: ci sono follower sincronizzati e, se non ci sono, \u00e8 consentito passare a una replica non sincronizzata. Ma non complicchiamo per ora.<\/p>\n

Il broker 3 esce dalla rete, e per la partizione 2 viene scelto un nuovo leader sul broker 2.<\/p>\n

\"RabbitMQ
\nFig. 2. Il broker 3 muore, e il suo follower sul broker 2 viene scelto come nuovo leader della partizione 2<\/i><\/p>\n

Poi il broker 1 esce e anche la partizione 1 perde il suo leader, il cui ruolo passa al broker 2.<\/p>\n

\"RabbitMQ
\nFig. 3. Rimane solo un broker. Tutti i leader si trovano su un solo broker con zero ridondanza<\/i><\/p>\n

Quando il broker 1 ritorna in rete, aggiunge quattro follower, fornendo una certa ridondanza a ogni partizione. Ma tutti i leader rimangono ancora sul broker 2.<\/p>\n

\"RabbitMQ
\nFig. 4. I leader rimangono sul broker 2<\/i><\/p>\n

Quando il broker 3 si riavvia, torniamo a tre repliche per partizione. Ma tutti i leader rimangono ancora sul broker 2.<\/p>\n

\"RabbitMQ
\nFig. 5. Distribuzione sbilanciata dei leader dopo il ripristino dei broker 1 e 3<\/i><\/p>\n

Kafka ha uno strumento per un riequilibrio dei leader di qualit\u00e0 superiore rispetto a RabbitMQ. Qui si doveva utilizzare un plugin o uno script esterno che modificava le politiche per migrare il nodo principale, riducendo la ridondanza durante la migrazione. Inoltre, per code di grandi dimensioni, si doveva accettare l'inaccessibilit\u00e0 durante la sincronizzazione.<\/p>\n

Kafka ha un concetto di \"repliche preferite\" per il ruolo di leader. Quando vengono creati i topic, Kafka cerca di distribuire uniformemente i leader tra i nodi e contrassegna questi primi leader come preferiti. Col passare del tempo, a causa del riavvio dei server, guasti e interruzioni di connettivit\u00e0, i leader possono trovarsi su altri nodi, come nel caso estremo descritto sopra.<\/p>\n

Per risolvere questo problema, Kafka offre due opzioni:<\/p>\n