{"id":32632,"date":"2019-10-31T21:48:08","date_gmt":"2019-10-31T18:48:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:48:08","modified_gmt":"2019-10-31T18:48:08","slug":"ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"Nicht nur Verarbeitung: Wie wir aus Kafka Streams eine verteilte Datenbank gemacht haben und was daraus entstanden ist","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habr!<\/p>\n

Wir erinnern daran, dass wir nach dem Buch \u00fcber Kafka<\/a><\/noindex> ein ebenso interessantes Werk \u00fcber die Bibliothek Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"Nicht
\n
\nW\u00e4hrend die Community gerade die Grenzen der M\u00f6glichkeiten dieses leistungsstarken Werkzeugs entdeckt, ist k\u00fcrzlich ein Artikel erschienen, mit dessen \u00dcbersetzung wir Sie bekannt machen m\u00f6chten. Der Autor berichtet aus eigener Erfahrung, wie man aus Kafka Streams ein verteiltes Datenspeicher erstellen kann. Viel Spa\u00df beim Lesen!
\n<\/a><\/noindex>
\nDie Apache-Bibliothek Kafka Streams<\/a><\/noindex> wird weltweit in Unternehmen f\u00fcr die verteilte Echtzeitverarbeitung \u00fcber Apache Kafka eingesetzt. Einer der oft untersch\u00e4tzten Aspekte dieses Frameworks ist, dass es erm\u00f6glicht, einen lokalen Zustand zu speichern, der auf der Grundlage der Streamverarbeitung erzeugt wird.<\/p>\n

In diesem Artikel erkl\u00e4re ich, wie es unserem Unternehmen gelungen ist, diese Gelegenheit gewinnbringend zu nutzen, w\u00e4hrend wir ein Produkt zur Sicherheit von Cloud-Anwendungen entwickelt haben. Mithilfe von Kafka Streams haben wir Microservices mit gemeinsamem Zustand erstellt, die jeweils als fehlertolerante und hochverf\u00fcgbare Quelle zuverl\u00e4ssiger Informationen \u00fcber den Status der Objekte im System dienen. Dies ist f\u00fcr uns ein Schritt nach vorn in Bezug auf Zuverl\u00e4ssigkeit und Wartungsfreundlichkeit.<\/p>\n

Falls Sie an einem alternativen Ansatz interessiert sind, der es erm\u00f6glicht, eine zentrale Datenbank zur Unterst\u00fctzung des formalen Zustands Ihrer Objekte zu nutzen \u2013 lesen Sie weiter, es k\u00f6nnte interessant sein... <\/p>\n

Warum wir der Meinung waren, dass es an der Zeit ist, unsere Ans\u00e4tze zum Management des gemeinsamen Zustands zu \u00fcberdenken <\/b><\/p>\n

Wir mussten den Zustand verschiedener Objekte basierend auf den Berichten von Agenten aufrechterhalten (zum Beispiel: Wurde die Website angegriffen?). Vor der Umstellung auf Kafka Streams waren wir oft auf eine zentrale Datenbank (+ Service-API) angewiesen, um den Zustand zu verwalten. Dieser Ansatz hat jedoch seine Nachteile: in datenintensiven Situationen<\/a><\/noindex> Die Unterst\u00fctzung von Konsistenz und Synchronisierung wird zu einer echten Herausforderung. Die Datenbank kann zum Engpass werden oder sich in einem Zustand der Race Conditions befinden<\/a><\/noindex> und unter Unberechenbarkeit leiden.<\/p>\n

\"Nicht
\n
\nAbbildung 1: Ein typisches Szenario mit Zustandsteilung, das vor dem \u00dcbergang zu
\nKafka und Kafka Streams auftrat: Die Agenten berichten ihre Zust\u00e4nde \u00fcber eine API, und der aktualisierte Zustand wird \u00fcber eine zentrale Datenbank berechnet. <\/i><\/p>\n

Lernen Sie Kafka Streams kennen \u2013 es ist jetzt einfach, Mikroservices mit gemeinsamem Zustand zu erstellen. <\/b><\/p>\n

Vor etwa einem Jahr haben wir beschlossen, unsere Szenarien f\u00fcr die Arbeit mit gemeinsamem Zustand gr\u00fcndlich zu \u00fcberdenken, um diese Probleme zu l\u00f6sen. Wir haben uns sofort entschieden, Kafka Streams auszuprobieren \u2013 bekannt f\u00fcr seine Skalierbarkeit, hohe Verf\u00fcgbarkeit und Fehlertoleranz sowie seinen umfangreichen Streaming-Funktionalit\u00e4ten (einschlie\u00dflich Statusbehalten). Genau das, was wir ben\u00f6tigten, ganz zu schweigen von der Reife und Zuverl\u00e4ssigkeit des Messaging-Systems, das in Kafka entstanden ist.<\/p>\n

Jeder von uns erstellte zustandsbehaftete Mikroservice wurde auf der Grundlage einer Kafka Streams-Instanz mit einer relativ einfachen Topologie aufgebaut. Diese bestand aus 1) einer Quelle, 2) einem Prozessor mit persistentem Schl\u00fcssel-Wert-Speicher und 3) einem Strom:<\/p>\n

\"Nicht
\n
\nAbbildung 2: Die standardm\u00e4\u00dfige Topologie unserer Streaming-Instanzen f\u00fcr zustandsbehaftete Mikroservices. Beachten Sie, dass es hier auch einen Speicher gibt, der Metadaten zur Planung enth\u00e4lt. <\/i><\/p>\n

Bei diesem neuen Ansatz erstellen die Agenten Nachrichten, die in das urspr\u00fcngliche Thema eingegeben werden, w\u00e4hrend die Verbraucher \u2013 beispielsweise der Benachrichtigungsdienst \u2013 den berechneten gemeinsamen Zustand \u00fcber den Strom (das Ausgangsthema) empfangen.<\/p>\n

\"Nicht
\n
\nAbbildung 3: Ein neues Beispiel f\u00fcr einen Aufgabenfluss f\u00fcr ein Szenario mit gemeinsamen Mikroservices: 1) Der Agent erzeugt eine Nachricht, die in das urspr\u00fcngliche Kafka-Thema gelangt; 2) der zustandsbehaftete Mikroservice (der Kafka Streams verwendet) verarbeitet sie und schreibt den berechneten Zustand in das endg\u00fcltige Kafka-Thema; danach 3) empfangen die Verbraucher den neuen Zustand.<\/i><\/p>\n

Hey, und dieser eingebaute Schl\u00fcssel-Wert-Speicher ist tats\u00e4chlich sehr n\u00fctzlich!<\/b><\/p>\n

Wie bereits erw\u00e4hnt, enth\u00e4lt unsere Topologie mit gemeinsamem Zustand einen Schl\u00fcssel-Wert-Speicher. Wir haben mehrere Verwendungsm\u00f6glichkeiten gefunden, von denen zwei im Folgenden beschrieben werden.<\/p>\n

Option #1: Verwendung des Schl\u00fcssel-Wert-Speichers bei Berechnungen<\/b><\/i><\/p>\n

Unser erster Schl\u00fcssel-Wert-Speicher enthielt Hilfsdaten, die wir f\u00fcr Berechnungen ben\u00f6tigten. Zum Beispiel wurde in einigen F\u00e4llen der gemeinsame Zustand nach dem Prinzip \u201eMehrheitsentscheid\u201c bestimmt. Im Speicher konnten alle neuesten Berichte der Agenten \u00fcber den Zustand eines bestimmten Objekts aufbewahrt werden. Wenn wir dann einen neuen Bericht von einem Agenten erhielten, konnten wir ihn speichern, die Berichte aller anderen Agenten \u00fcber den Zustand desselben Objekts aus dem Speicher abrufen und die Berechnung wiederholen.
\nIn Abbildung 4 unten ist zu sehen, wie wir den Zugriff auf den Schl\u00fcssel-Wert-Speicher f\u00fcr die verarbeitende Methode des Prozessors er\u00f6ffneten, sodass eine neue Nachricht anschlie\u00dfend verarbeitet werden konnte.<\/p>\n

\"Nicht
\n
\nAbbildung 4: Zugriff auf den Schl\u00fcssel-Wert-Speicher f\u00fcr die verarbeitende Methode des Prozessors gew\u00e4hren (danach muss in jedem Szenario, das mit gemeinsam genutztem Zustand arbeitet, die Methode implementiert werden) doProcess<\/code>)<\/i><\/p>\n

Option #2: Erstellung eines CRUD-API \u00fcber Kafka Streams<\/b><\/i><\/p>\n

Nachdem wir unseren grundlegenden Aufgabenstrom eingerichtet hatten, versuchten wir, ein RESTful CRUD-API f\u00fcr unsere Mikrodienste mit gemeinsam genutztem Zustand zu schreiben. Wir wollten in der Lage sein, den Zustand bestimmter oder aller Objekte abzurufen sowie den Zustand eines Objekts festzulegen oder zu entfernen (dies ist n\u00fctzlich f\u00fcr die Unterst\u00fctzung der Server-Seite).<\/p>\n

Um alle API Get State zu unterst\u00fctzen, lagerten wir den Zustand jedes Mal, wenn wir ihn bei der Verarbeitung neu berechnen mussten, f\u00fcr l\u00e4ngere Zeit im eingebetteten Schl\u00fcssel-Wert-Speicher. In diesem Fall wird es recht einfach, ein solches API mit einer einzigen Instanz von Kafka Streams zu implementieren, wie im unten stehenden Listing gezeigt:<\/p>\n

\"Nicht
\n
\nAbbildung 5: Nutzung des eingebetteten Schl\u00fcssel-Wert-Speichers zur Abfrage des vorab berechneten Objektzustands <\/i><\/p>\n

Die Aktualisierung des Objektstatus \u00fcber die API l\u00e4sst sich ebenfalls unkompliziert umsetzen. Im Grunde genommen muss daf\u00fcr lediglich ein Kafka-Producer erstellt werden, der dann eine Aufzeichnung vornimmt, die den neuen Status enth\u00e4lt. Auf diese Weise wird sichergestellt, dass alle \u00fcber die API generierten Nachrichten genau wie die von anderen Produzenten (z.B. Agents) verarbeitet werden.<\/p>\n

\"Nicht
\n
\nAbbildung 6: Den Objektstatus k\u00f6nnen Sie mithilfe eines Kafka-Producers festlegen. <\/i><\/p>\n

Eine kleine Komplikation: Kafka hat zahlreiche Partitionen.<\/b><\/p>\n

Im weiteren Verlauf hatten wir das Ziel, die mit der Verarbeitung verbundene Last zu verteilen und die Verf\u00fcgbarkeit zu verbessern, indem wir f\u00fcr jedes Szenario ein Cluster von Mikrodiensten mit gemeinsamem Status bereitstellen. Die Einrichtung war erstaunlich einfach: Nachdem wir alle Instanzen konfiguriert hatten, sodass sie mit derselben Anwendungs-ID (und denselben Boot-Servern) arbeiteten, geschah fast alles automatisch. Wir hatten zudem festgelegt, dass jedes urspr\u00fcngliche Thema aus mehreren Partitionen bestehen wird, damit jeder Instanz eine Teilmenge dieser Partitionen zugewiesen werden kann.<\/p>\n

Ich m\u00f6chte auch erw\u00e4hnen, dass es hier \u00fcblich ist, ein Zustandsspeicher-Backup zu erstellen, um beispielsweise im Falle einer Wiederherstellung nach einem Ausfall diese Kopie auf eine andere Instanz zu \u00fcbertragen. F\u00fcr jeden Zustandsspeicher in Kafka Streams wird ein replizierbares Topic mit einem \u00c4nderungsprotokoll erstellt (in dem lokale Updates verfolgt werden). Dadurch sichert Kafka kontinuierlich den Zustandsspeicher ab. Daher kann im Falle eines Ausfalls einer bestimmten Kafka Streams-Instanz der Zustandsspeicher schnell auf eine andere Instanz wiederhergestellt werden, wo die entsprechenden Partitionen \u00fcbertragen werden. Unsere Tests haben gezeigt, dass dies innerhalb von Sekunden erfolgt, selbst wenn Millionen von Eintr\u00e4gen im Zustandsspeicher vorhanden sind.<\/p>\n

Der \u00dcbergang von einem Mikroservice mit gemeinsamem Zustand zu einem Cluster von Mikroservices macht die Implementierung der Get State API nicht trivial. In der neuen Situation enth\u00e4lt der Zustandsspeicher jedes Mikroservices nur einen Teil des Gesamtbildes (n\u00e4mlich die Objekte, deren Schl\u00fcssel einer bestimmten Partition zugeordnet waren). Wir mussten feststellen, auf welchem Instanz der Zustand des ben\u00f6tigten Objekts gespeichert war, und das geschah anhand der Metadaten der Streams, wie unten gezeigt:<\/p>\n

\"Nicht
\n
\nAbbildung 7: Mithilfe von Metadaten der Streams bestimmen wir, von welcher Instanz wir den Zustand des ben\u00f6tigten Objekts abfragen; ein \u00e4hnlicher Ansatz wurde auch beim GET ALL API angewendet.<\/i><\/p>\n

Wesentliche Erkenntnisse<\/b><\/p>\n

Zustandsspeicher in Kafka Streams k\u00f6nnen de facto als verteilte Datenbank fungieren, <\/p>\n