{"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\/de\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost","title":{"rendered":"RabbitMQ gegen Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"RabbitMQ
\n
\nIm im vorherigen Artikel<\/a><\/noindex> Wir haben die Clusterbildung von RabbitMQ zur Gew\u00e4hrleistung der Ausfallsicherheit und hohen Verf\u00fcgbarkeit betrachtet. Jetzt tauchen wir tiefer in Apache Kafka ein.<\/p>\n

Hier ist die Replikationseinheit die Partition. Jedes Thema hat ein oder mehrere Partitionen. In jeder Partition gibt es einen Leader mit oder ohne Follower. Bei der Erstellung eines Themas wird die Anzahl der Partitionen und der Replikationsfaktor angegeben. Ein h\u00e4ufig verwendeter Wert ist 3, was drei Replikate bedeutet: ein Leader und zwei Follower.
\n<\/a><\/noindex><\/p>\n

\"RabbitMQ
\nAbb. 1. Vier Partitionen sind auf drei Broker verteilt<\/i><\/p>\n

Alle Lese- und Schreibanfragen werden an den Leader gesendet. Follower senden dem Leader regelm\u00e4\u00dfig Anfragen nach den neuesten Nachrichten. Verbraucher wenden sich niemals an Follower; diese existieren nur f\u00fcr Redundanz und Ausfallsicherheit.<\/p>\n

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

Ausfall einer Partition<\/h1>\n

\nWenn ein Broker ausf\u00e4llt, fallen h\u00e4ufig die Leader mehrerer Partitionen aus. In jeder von ihnen wird ein Follower von einem anderen Knoten zum Leader. Tats\u00e4chlich ist dies nicht immer so, da auch der Synchronisationsfaktor eine Rolle spielt: Gibt es synchronisierte Follower und wenn nicht, ist der \u00dcbergang zu einer unsynchronisierten Replikat erlaubt? Aber lass uns das vorerst nicht komplizieren.<\/p>\n

Broker 3 f\u00e4llt aus \u2014 und f\u00fcr Partition 2 wird ein neuer Leader auf Broker 2 gew\u00e4hlt.<\/p>\n

\"RabbitMQ
\nAbb. 2. Broker 3 stirbt, und sein Follower auf Broker 2 wird neuer Leader von Partition 2<\/i><\/p>\n

Dann f\u00e4llt Broker 1 aus und Partition 1 verliert ebenfalls ihren Leader, dessen Rolle auf Broker 2 \u00fcbergeht.<\/p>\n

\"RabbitMQ
\nAbb. 3. Nur ein Broker bleibt. Alle Leader befinden sich auf einem Broker mit null Redundanz<\/i><\/p>\n

Wenn Broker 1 ins Netzwerk zur\u00fcckkehrt, f\u00fcgt er vier Follower hinzu, sodass jedem Abschnitt eine gewisse Redundanz geboten wird. Aber alle Leader bleiben weiterhin auf Broker 2.<\/p>\n

\"RabbitMQ
\nAbb. 4. Die Leader bleiben auf Broker 2<\/i><\/p>\n

Wenn Broker 3 wieder hochgefahren wird, kehren wir zu drei Replikaten pro Partition zur\u00fcck. Aber alle Leader bleiben weiterhin auf Broker 2.<\/p>\n

\"RabbitMQ
\nAbb. 5. Unausgewogene Verteilung der Leader nach der Wiederherstellung der Broker 1 und 3<\/i><\/p>\n

Kafka verf\u00fcgt \u00fcber ein Werkzeug zur hochwertigeren Neubesetzung von Leadern als RabbitMQ. Dort musste ein externes Plugin oder Skript verwendet werden, das die Richtlinien zur Migration des Hauptknotens \u00e4nderte, um die Redundanz w\u00e4hrend der Migration zu verringern. Au\u00dferdem musste man sich bei gro\u00dfen Warteschlangen mit einer Unzug\u00e4nglichkeit w\u00e4hrend der Synchronisation abfinden.<\/p>\n

Kafka hat das Konzept der \"bevorzugten Replikate\" f\u00fcr die Rolle des Leaders. Wenn Partitionen eines Topics erstellt werden, versucht Kafka, die Leader gleichm\u00e4\u00dfig auf die Knoten zu verteilen und markiert diese ersten Leader als bevorzugt. Im Laufe der Zeit k\u00f6nnen die Leader aufgrund von Serverneustarts, Ausf\u00e4llen und Verbindungseinbu\u00dfen auf anderen Knoten landen, wie im vorher beschriebenen Extremfall.<\/p>\n

Um dies zu beheben, bietet Kafka zwei Optionen:<\/p>\n