{"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 geworden ist","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, Habra!<\/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
\nDas Community erkundet erst die Grenzen der M\u00f6glichkeiten dieses leistungsstarken Instruments. K\u00fcrzlich erschien ein Artikel, mit dessen \u00dcbersetzung wir Sie bekannt machen m\u00f6chten. Der Autor berichtet aus eigener Erfahrung, wie man mit Kafka Streams ein verteiltes Datenspeicher erstellt. Viel Spa\u00df beim Lesen!
\n<\/a><\/noindex>
\nDie Apache-Bibliothek Kafka Streams<\/a><\/noindex> wird weltweit in Unternehmen f\u00fcr die verteilte Stream-Verarbeitung \u00fcber Apache Kafka eingesetzt. Ein oft untersch\u00e4tzter Aspekt dieses Frameworks ist, dass es erm\u00f6glicht, einen lokalen Zustand zu speichern, der auf der Stream-Verarbeitung basiert.<\/p>\n

In diesem Artikel erkl\u00e4re ich, wie es uns in unserem Unternehmen gelungen ist, diese Funktion gewinnbringend bei der Entwicklung eines Produkts zur Sicherheit von Cloud-Anwendungen zu nutzen. Mit Kafka Streams haben wir Mikrodienste mit gemeinsamem Zustand erstellt, die uns als ausfallsichere und hochverf\u00fcgbare Informationsquelle \u00fcber den Zustand der Objekte im System dienen. Dies ist ein Fortschritt in Bezug auf Zuverl\u00e4ssigkeit und Wartungsfreundlichkeit.<\/p>\n

Wenn Sie an einem alternativen Ansatz interessiert sind, der es erm\u00f6glicht, eine zentrale Datenbank zur Unterst\u00fctzung des formalen Zustands Ihrer Objekte zu verwenden \u2013 lesen Sie weiter, das wird interessant... <\/p>\n

Warum wir der Meinung sind, dass es an der Zeit war, unsere Ans\u00e4tze zum Umgang mit gemeinsamem Zustand zu \u00e4ndern <\/b><\/p>\n

Wir mussten den Zustand verschiedener Objekte im Hinblick auf Agentenberichte aufrechterhalten (z.B.: Wurde die Website angegriffen?). Vor dem Wechsel zu Kafka Streams waren wir oft auf eine zentrale Datenbank (+ Service API) zur Verwaltung des Zustands angewiesen. Dieser Ansatz hat seine Nachteile: In datenintensiven Situationen<\/a><\/noindex> wird die Aufrechterhaltung von Konsistenz und Synchronisation zur echten Herausforderung. Die Datenbank kann zum Engpass werden oder sich in Wettbewerbszust\u00e4nden<\/a><\/noindex> befinden und unter Unvorhersehbarkeiten leiden.<\/p>\n

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

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

Vor etwa einem Jahr haben wir beschlossen, unsere Arbeitsabl\u00e4ufe mit gemeinsamem Zustand gr\u00fcndlich zu \u00fcberarbeiten, um einige Probleme zu l\u00f6sen. Sofort haben wir Kafka Streams ausprobiert \u2013 bekannt daf\u00fcr, wie skalierbar, hochverf\u00fcgbar und fehlertolerant sie ist, und welchen reichen Streaming-Funktionsumfang sie bietet (unter anderem auch Berechnungen mit Zustandsbewahrung). Genau das, was wir ben\u00f6tigten, ganz zu schweigen von der Reife und Zuverl\u00e4ssigkeit des Nachrichtenaustauschs, die sich in Kafka entwickelt hat.<\/p>\n

Jeder unserer entwickelten Microservices zur Zustandsbewahrung basierte auf einer Instanz von Kafka Streams mit einer recht einfachen Topologie. Diese bestand aus 1) einer Quelle 2) einem Prozessor mit persistentem Key-Value-Speicher 3) einem Strom:<\/p>\n

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

Mit diesem neuen Ansatz erstellen Agenten Nachrichten, die in das urspr\u00fcngliche Thema eingespeist werden, w\u00e4hrend Verbraucher \u2013 sagen wir, der Dienst f\u00fcr E-Mail-Benachrichtigungen \u2013 den berechneten gemeinsamen Zustand \u00fcber den Strom (Ausgangsthema) empfangen.<\/p>\n

\"Nicht
\n
\nAbbildung 3: Ein neues Beispiel f\u00fcr einen Aufgabestrom f\u00fcr das Szenario mit gemeinsamen Microservices: 1) der Agent erzeugt eine Nachricht, die in das urspr\u00fcngliche Kafka-Thema gelangt; 2) der Microservice mit gemeinsamem Zustand (der Kafka Streams verwendet) verarbeitet sie und schreibt den berechneten Zustand in das Endthema von Kafka; anschlie\u00dfend 3) empfangen die Verbraucher den neuen Zustand.<\/i><\/p>\n

Hey, und dieser eingebaute Key-Value-Speicher ist wirklich sehr n\u00fctzlich!<\/b><\/p>\n

Wie oben erw\u00e4hnt, enth\u00e4lt unsere Topologie mit gemeinsamem Zustand einen Key-Value-Speicher. Wir haben mehrere Verwendungsm\u00f6glichkeiten gefunden, und zwei davon sind unten beschrieben.<\/p>\n

Option #1: Verwendung des Key-Value-Speichers bei Berechnungen<\/b><\/i><\/p>\n

Unser erstes Schl\u00fcssel-Wert-Speicher enthielt Hilfsdaten, die wir f\u00fcr unsere Berechnungen ben\u00f6tigten. Beispielsweise wurde in einigen F\u00e4llen der geteilte Zustand nach dem Prinzip der \"Mehrheit der Stimmen\" bestimmt. Im Speicher konnten wir alle letzten Berichte der Agenten \u00fcber den Zustand eines bestimmten Objekts aufbewahren. Anschlie\u00dfend konnten wir, nachdem wir einen neuen Bericht von einem der Agenten erhalten hatten, diesen speichern, die Berichte aller anderen Agenten \u00fcber den Zustand desselben Objekts aus dem Speicher abrufen und die Berechnung wiederholen.
\nIn der Abbildung 4 unten wird gezeigt, wie wir den Zugriff auf den Schl\u00fcssel-Wert-Speicher f\u00fcr die verarbeitende Methode des Prozessors ge\u00f6ffnet haben, sodass anschlie\u00dfend eine neue Nachricht verarbeitet werden konnte.<\/p>\n

\"Nicht
\n
\nAbbildung 4: Zugriff auf den Schl\u00fcssel-Wert-Speicher f\u00fcr die verarbeitende Methode des Prozessors \u00f6ffnen (nachdem in jedem Szenario, das mit dem geteilten Zustand arbeitet, die Methode implementiert werden musste. doProcess<\/code>)<\/i><\/p>\n

Variante #2: Erstellen einer CRUD-API \u00fcber Kafka Streams<\/b><\/i><\/p>\n

Nachdem wir unseren grundlegenden Aufgabenstrom eingerichtet hatten, fingen wir an, eine RESTful CRUD-API f\u00fcr unsere Mikrodienste mit geteiltem Zustand zu schreiben. Wir wollten es erm\u00f6glichen, den Zustand einiger oder aller Objekte abzurufen sowie den Zustand eines Objekts festzulegen oder zu l\u00f6schen (dies ist n\u00fctzlich f\u00fcr die Unterst\u00fctzung der Backend-Seite).<\/p>\n

Um alle API Get State zu unterst\u00fctzen, haben wir jedes Mal, wenn wir den Zustand bei der Verarbeitung neu berechnen mussten, diesen langfristig im integrierten Schl\u00fcssel-Wert-Speicher abgelegt. In diesem Fall ist es ausreichend, eine solche API mit einer einzelnen Instanz von Kafka Streams zu implementieren, wie im folgenden Listing gezeigt:<\/p>\n

\"Nicht
\n
\nAbbildung 5: Verwendung des integrierten Schl\u00fcssel-Wert-Speichers zur Abfrage des vorcomputierten Zustands eines Objekts <\/i><\/p>\n

Die Aktualisierung des Zustands eines Objekts \u00fcber die API ist ebenfalls nicht schwer zu realisieren. Prinzipiell muss man daf\u00fcr nur einen Kafka-Producer erstellen und damit einen Eintrag vornehmen, der den neuen Zustand enth\u00e4lt. So wird sichergestellt, dass alle \u00fcber die API generierten Nachrichten genau so verarbeitet werden, wie die von anderen Produzenten (z. B. Agenten) eintreffenden Nachrichten.<\/p>\n

\"Nicht
\n
\nAbbildung 6: Den Zustand eines Objekts kann man mit einem Kafka-Producer festlegen <\/i><\/p>\n

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

Anschlie\u00dfend wollten wir die mit der Verarbeitung verbundene Last verteilen und die Verf\u00fcgbarkeit verbessern, indem wir f\u00fcr jedes Szenario einen Cluster von Mikrodiensten mit gemeinsamem Zustand bereitstellen. Die Einrichtung fiel uns leicht: nachdem wir alle Instanzen konfiguriert hatten, damit sie mit derselben Anwendungs-ID (und denselben Bootservern) arbeiten, geschah praktisch alles andere automatisch. Wir haben auch festgelegt, dass jedes Ausgangsthema aus mehreren Partitionen bestehen sollte, sodass jeder Instanz ein Teilmenge dieser Partitionen zugewiesen werden konnte.<\/p>\n

Ich m\u00f6chte auch erw\u00e4hnen, dass es hier \u00fcblich ist, ein Backup des Zustandspeichers zu erstellen, um beispielsweise im Falle einer Wiederherstellung nach einem Ausfall dieses Backup auf eine andere Instanz zu \u00fcbertragen. F\u00fcr jeden Zustandsspeicher in Kafka Streams wird ein replizierbares Thema mit einem \u00c4nderungsprotokoll erstellt (in dem lokale Aktualisierungen verfolgt werden). Auf diese Weise sch\u00fctzt Kafka st\u00e4ndig den Zustandsspeicher. Daher kann der Zustandsspeicher von Kafka Streams im Falle eines Ausfalls einer bestimmten Instanz schnell auf einer anderen Instanz wiederhergestellt werden, wo die entsprechenden Partitionen hin\u00fcbergehen. Unsere Tests haben gezeigt, dass dies in wenigen Sekunden geschieht, selbst wenn Millionen von Datens\u00e4tzen im Speicher sind.<\/p>\n

Der \u00dcbergang von einem Mikrodienst mit gemeinsamem Zustand zu einem Cluster von Mikrodiensten gestaltet sich nicht so trivial, wenn es darum geht, die Get State API zu implementieren. In der neuen Situation enth\u00e4lt der Zustandsspeicher jedes Mikrodienstes nur einen Teil des Gesamtbildes (die Objekte, deren Schl\u00fcssel auf eine bestimmte Partition abgebildet sind). Wir mussten bestimmen, auf welcher Instanz sich der Zustand des ben\u00f6tigten Objekts befand, und dies geschah anhand der Metadatenstr\u00f6me, wie unten gezeigt:<\/p>\n

\"Nicht
\n
\nAbbildung 7: Mithilfe von Metadatenstr\u00f6men bestimmen wir, von welcher Instanz wir den Zustand des ben\u00f6tigten Objekts anfordern; ein solcher Ansatz wurde mit der GET ALL API angewendet.<\/i><\/p>\n

Wichtigste Ergebnisse<\/b><\/p>\n

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