{"id":38172,"date":"2019-10-31T22:22:05","date_gmt":"2019-10-31T19:22:05","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\/"},"modified":"2019-10-31T22:22:05","modified_gmt":"2019-10-31T19:22:05","slug":"ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","title":{"rendered":"Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Mechanik des Nachrichtenaustauschs durch ActiveMQ und Kafka. Kapitel 3. Kafka","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Fortsetzung der \u00dcbersetzung eines kleinen Buches:<br \/>\n\"Understanding Message Brokers\",<br \/>\nAutor: Jakub Korab, Verlag: O'Reilly Media, Inc., Ver\u00f6ffentlichungsdatum: Juni 2017, ISBN: 9781492049296.<\/p>\n<p>Vorheriger \u00fcbersetzter Teil: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Nachrichten\u00fcbertragungsmechanismen mit ActiveMQ und Kafka. Kapitel 1. Einf\u00fchrung<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>KAPITEL 3<\/h2>\n<p><\/p>\n<h2>Kafka<\/h2>\n<p>\nKafka wurde bei LinkedIn entwickelt, um einige Einschr\u00e4nkungen traditioneller Nachrichtenbroker zu umgehen und die Notwendigkeit zu vermeiden, mehrere Nachrichtenbroker f\u00fcr unterschiedliche Punkt-zu-Punkt-Interaktionen einzurichten. Dies wird in diesem Buch im Abschnitt \"Vertikale und horizontale Skalierung\" auf Seite 28 beschrieben. Die Anwendungsf\u00e4lle bei LinkedIn basierten haupts\u00e4chlich auf der einseitigen Verarbeitung von sehr gro\u00dfen Datenmengen, wie Seitenklicks und Zugriffsprotokollen, und erm\u00f6glichten es gleichzeitig, dass mehrere Systeme diese Daten nutzen, ohne die Leistung von Produzenten oder anderen Konsumenten zu beeintr\u00e4chtigen. Tats\u00e4chlich besteht der Grund f\u00fcr die Existenz von Kafka darin, eine solche Architektur f\u00fcr den Nachrichtenaustausch zu schaffen, wie sie in der Universal Data Pipeline beschrieben wird.<\/p>\n<p>Angesichts dieses Ziels entstanden nat\u00fcrlich auch andere Anforderungen. Kafka muss:<\/p>\n<ul>\n<li>\u00e4u\u00dferst schnell sein<\/li>\n<li>eine hohe Bandbreite bei der Nachrichtenverarbeitung bieten<\/li>\n<li>die Modelle \u201ePublisher-Subscriber\u201c und \u201ePoint-to-Point\u201c unterst\u00fctzen<\/li>\n<li>Z\u00f6gern Sie nicht, neue Verbraucher hinzuzuf\u00fcgen. Beispielsweise nimmt die Leistung und die Warteschlange eines Themas in ActiveMQ ab, wenn die Anzahl der Verbraucher am Zielort steigt.<\/li>\n<li>Skalierbarkeit in der Breite; wenn ein Broker, der Nachrichten speichert, dies nur mit der maximalen Geschwindigkeit der Festplatte tun kann, macht es Sinn, \u00fcber ein einzelnes Broker-Exemplar hinauszugehen, um die Leistung zu steigern.<\/li>\n<li>Zugriff auf die Speicherung und das Abrufen von Nachrichten trennen.<\/li>\n<\/ul>\n<p>\nUm all dies zu erreichen, verwendet Kafka eine Architektur, die die Rollen und Aufgaben von Clients und Message Brokers neu definiert hat. Das JMS-Modell ist stark brokerzentriert, wo der Broker f\u00fcr die Verbreitung von Nachrichten verantwortlich ist, w\u00e4hrend die Clients sich nur um das Senden und Empfangen von Nachrichten k\u00fcmmern m\u00fcssen. Kafka hingegen ist clientorientiert, wobei der Client viele Funktionen eines traditionellen Brokers \u00fcbernimmt, z. B. die faire Verteilung relevanter Nachrichten unter den Verbrauchern, und im Gegenzug einen extrem schnellen und skalierbaren Broker erh\u00e4lt. F\u00fcr Personen, die mit traditionellen Messaging-Systemen gearbeitet haben, erfordert die Arbeit mit Kafka grundlegende Ver\u00e4nderungen in der Denkweise.<br \/>\nDiese Ingenieuransatz f\u00fchrte zur Schaffung einer Messaging-Infrastruktur, die die Durchsatzkapazit\u00e4t im Vergleich zu herk\u00f6mmlichen Brokern um ein Vielfaches steigern kann. Wie wir sehen werden, ist dieser Ansatz jedoch mit Kompromissen verbunden, die bedeuten, dass Kafka f\u00fcr bestimmte Arten von Lasten und Software nicht geeignet ist.<\/p>\n<h3>Einheitliches Adressmodell<\/h3>\n<p>\nUm die oben beschriebenen Anforderungen zu erf\u00fcllen, hat Kafka die Nachrichten\u00fcbermittlungstypen \"Ver\u00f6ffentlichung-Abonnement\" und \"Punkt-zu-Punkt\" innerhalb eines Typs von Adressaten kombiniert \u2014 <i>Thema<\/i>. Dies kann Personen verwirren, die mit Messaging-Systemen gearbeitet haben, bei denen das Wort \"Thema\" sich auf einen Broadcast-Mechanismus bezieht, bei dem das Lesen (aus dem Thema) nicht zuverl\u00e4ssig ist (nicht dauerhaft). Themen in Kafka sollten als hybrider Adresstyp betrachtet werden, gem\u00e4\u00df der Definition, die in der Einleitung zu diesem Buch gegeben wird.<\/p>\n<blockquote><p>In dem restlichen Teil dieses Kapitels, sofern nicht ausdr\u00fccklich anders angegeben, bezieht sich der Begriff \"Thema\" auf das Thema Kafka.<\/p><\/blockquote>\n<p>\nUm vollst\u00e4ndig zu verstehen, wie sich Themen verhalten und welche Garantien sie bieten, m\u00fcssen wir zun\u00e4chst betrachten, wie sie in Kafka implementiert sind.<br \/>\n<i>Jedes Thema in Kafka hat sein eigenes Journal.<\/i><br \/>\nProduzenten, die Nachrichten an Kafka senden, f\u00fcgen diesen Journaleintr\u00e4gen hinzu, w\u00e4hrend Konsumenten aus dem Journal mit Hilfe von Zeigern lesen, die stetig nach vorne bewegt werden. Periodisch entfernt Kafka die \u00e4ltesten Teile des Journals, unabh\u00e4ngig davon, ob die Nachrichten in diesen Teilen gelesen wurden oder nicht. Ein zentrales Element des Designs von Kafka ist, dass der Broker nicht darauf achtet, ob Nachrichten gelesen wurden oder nicht \u2014 das ist die Verantwortung des Clients.<\/p>\n<blockquote><p>Die Begriffe \u201eJournal\u201c und \u201eZeiger\u201c sind nicht in der <noindex><a rel=\"nofollow\" href=\"https:\/\/kafka.apache.org\/documentation.html\">Kafka-Dokumentation<\/a><\/noindex>. Diese allgemein bekannten Begriffe werden hier verwendet, um das Verst\u00e4ndnis zu erleichtern.<\/p><\/blockquote>\n<p>\nDieses Modell unterscheidet sich vollst\u00e4ndig von ActiveMQ, wo Nachrichten aus allen Warteschlangen in einem einzigen Journal gespeichert werden und der Broker die Nachrichten als gel\u00f6scht markiert, nachdem sie gelesen wurden.<br \/>\nLassen Sie uns nun etwas tiefer gehen und das Journal des Themas genauer betrachten.<br \/>\nDas Kafka-Journal besteht aus mehreren Partitionen (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/tm\/w2\/yf\/tmw2yf3lanppqtrumxoidotplhi.png\">Abbildung 3-1<\/a><\/noindex>). Kafka gew\u00e4hrleistet eine strikte Reihenfolge in jeder Partition. Das bedeutet, dass Nachrichten, die in einer bestimmten Reihenfolge in eine Partition geschrieben werden, auch in der gleichen Reihenfolge gelesen werden. Jede Partition wird als kreisf\u00f6rmige (rolling) Logdatei umgesetzt, die enth\u00e4lt <i>eine Teilmenge <\/i>(Subset) aller Nachrichten, die von seinen Produzenten an das Topic gesendet wurden. Das erstellte Topic hat standardm\u00e4\u00dfig eine Partition. Die Idee der Partitionen ist das zentrale Konzept von Kafka f\u00fcr horizontale Skalierung.<\/p>\n<p><img decoding=\"async\" alt=\"Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Mechanik des Nachrichtenaustauschs durch ActiveMQ und Kafka. Kapitel 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/39f41ebcb73ec247656c0dea438158a9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 3-1. Kafka-Partitionen<\/i><\/p>\n<p>Wenn ein Produzent eine Nachricht an ein Kafka-Topic sendet, entscheidet er, in welche Partition die Nachricht gesendet werden soll. Wir werden dies sp\u00e4ter ausf\u00fchrlicher betrachten.<\/p>\n<h2>Nachrichten lesen<\/h2>\n<p>\nEin Client, der Nachrichten lesen m\u00f6chte, verwaltet einen benannten Zeiger, der als <i>Consumer-Gruppe (consumer group)<\/i>bezeichnet wird, der auf <i>den Offset<\/i> der Nachricht in der Partition verweist. Der Offset ist eine Position mit einer wachsenden Nummer, die bei 0 zu Beginn der Partition beginnt. Diese Consumer-Gruppe, auf die im API \u00fcber eine benutzerdefinierte Identifikation group_id verwiesen wird, entspricht <i>einem logischen Verbraucher oder System.<\/i>.<\/p>\n<p>Die meisten Messaging-Systeme lesen Daten vom Empf\u00e4nger \u00fcber mehrere Instanzen und Streams zur parallelen Verarbeitung von Nachrichten. In der Regel werden daher viele Consumer-Instanzen die gleiche Consumer-Gruppe gemeinsam nutzen.<\/p>\n<p>Das Leseproblem kann folgenderma\u00dfen dargestellt werden:<\/p>\n<ul>\n<li>Ein Topic hat mehrere Partitionen.<\/li>\n<li>Verschiedene Consumer-Gruppen k\u00f6nnen gleichzeitig auf dasselbe Topic zugreifen.<\/li>\n<li>Eine Consumer-Gruppe kann mehrere separate Instanzen haben.<\/li>\n<\/ul>\n<p>\nDies stellt ein nicht triviales \"viele zu viele\"-Problem dar. Um zu verstehen, wie Kafka die Beziehungen zwischen Consumer-Gruppen, Consumer-Instanzen und Partitionen handhabt, betrachten wir eine Reihe von zunehmend komplexeren Lese-Szenarien.<\/p>\n<h3>Consumer und Consumer-Gruppen<\/h3>\n<p>\nLassen Sie uns als Ausgangspunkt ein Topic mit einer Partition betrachten (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/6z\/tz\/dh\/6ztzdhqmjweck-z15htxb2xbe28.png\">Abbildung 3-2<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Mechanik des Nachrichtenaustauschs durch ActiveMQ und Kafka. Kapitel 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/46c92e6bd38774dfef3be4bd198bf35d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 3-2. Der Consumer liest aus der Partition<\/i><\/p>\n<p>Wenn eine Consumer-Instanz sich mit ihrer eigenen group_id mit diesem Topic verbindet, wird ihr eine Lese-Partition und ein Offset in dieser Partition zugewiesen. Der Wert dieses Offsets wird im Client konfiguriert, entweder als Zeiger auf die letzte Position (die neueste Nachricht) oder auf die fr\u00fcheste Position (die \u00e4lteste Nachricht). Der Consumer fragt Nachrichten aus dem Topic ab, was zu einer sequentiellen Wiedergabe aus dem Log f\u00fchrt.<br \/>\nDie Offset-Position wird regelm\u00e4\u00dfig zur\u00fcck in Kafka committed und als Nachrichten im internen Topic gespeichert. <i>_consumer_offsets<\/i>. Gelesene Nachrichten werden dennoch nicht gel\u00f6scht, im Gegensatz zu einem normalen Broker, und der Client kann das Offset zur\u00fcckspulen, um bereits betrachtete Nachrichten erneut zu verarbeiten.<\/p>\n<p>Wenn ein zweiter logischer Consumer mit einer anderen group_id verbunden wird, verwaltet dieser einen zweiten Zeiger, der unabh\u00e4ngig vom ersten ist (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/qe\/v1\/yk\/qev1yktga3s-g1gqlynylbe3n9w.png\">Abbildung 3-3<\/a><\/noindex>). Auf diese Weise fungiert ein Kafka-Topic als Warteschlange, in der es einen Consumer gibt und zus\u00e4tzlich ein typisches Publisher-Subscriber-Topic (pub-sub), bei dem mehrere Consumer abonniert sind. Ein weiterer Vorteil ist, dass alle Nachrichten gespeichert werden und mehrfach verarbeitet werden k\u00f6nnen.<\/p>\n<p><img decoding=\"async\" alt=\"Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Mechanik des Nachrichtenaustauschs durch ActiveMQ und Kafka. Kapitel 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/e9e8b9063ef7367005254d36abb47f4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 3-3. Zwei Consumer in verschiedenen Consumer-Gruppen lesen aus einer Partition.<\/i><\/p>\n<h3>Consumer in der Consumer-Gruppe.<\/h3>\n<p>\nWenn eine Instanz eines Consumers Daten aus einer Partition liest, hat sie die vollst\u00e4ndige Kontrolle \u00fcber den Zeiger und verarbeitet die Nachrichten wie im vorherigen Abschnitt beschrieben.<br \/>\nWenn mehrere Instanzen von Consumers mit derselben group_id zu einem Topic mit einer Partition verbunden sind, wird die Kontrolle \u00fcber den Zeiger an die Instanz \u00fcbergeben, die zuletzt verbunden ist, und ab diesem Zeitpunkt erh\u00e4lt sie alle Nachrichten (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/0j\/ao\/f2\/0jaof2mdwg3cqvmwemhtxkrltuq.png\">Abbildung 3-4<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Mechanik des Nachrichtenaustauschs durch ActiveMQ und Kafka. Kapitel 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/ec6af819445dad4028f65449a735ae22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 3-4. Zwei Consumer in derselben Consumer-Gruppe lesen aus einer Partition.<\/i><\/p>\n<p>Dieser Verarbeitungsmodus, bei dem die Anzahl der Verbraucherinstanzen die Anzahl der Partitionen \u00fcbersteigt, kann als eine Art monopolistischer Verbraucher betrachtet werden. Dies kann n\u00fctzlich sein, wenn Sie eine \u201eaktiv-passive\u201c (oder \u201ehei\u00df-warm\u201c) Clusterung Ihrer Verbraucherinstanzen ben\u00f6tigen, obwohl der parallele Betrieb mehrerer Verbraucher (\u201eaktiv-aktiv\u201c oder \u201ehei\u00df-hei\u00df\u201c) viel typischer ist als Verbraucher im Bereitschaftsmodus.<\/p>\n<blockquote><p>Das oben beschriebene Verhalten der Nachrichtenverteilung mag im Vergleich zu einer herk\u00f6mmlichen JMS-Warteschlange \u00fcberraschend erscheinen. In diesem Modell werden die in die Warteschlange gesendeten Nachrichten gleichm\u00e4\u00dfig zwischen zwei Verbrauchern verteilt.<\/p><\/blockquote>\n<p>\nH\u00e4ufig erstellen wir mehrere Verbraucherinstanzen entweder f\u00fcr die parallele Verarbeitung von Nachrichten, um die Lesegeschwindigkeit zu erh\u00f6hen, oder um die Stabilit\u00e4t des Leseprozesses zu verbessern. Da immer nur eine Verbraucherinstanz gleichzeitig Daten aus einer Partition lesen kann, wie wird dies in Kafka erreicht?<\/p>\n<p>Eine M\u00f6glichkeit, dies zu erreichen, besteht darin, eine einzelne Instanz des Consumers zu verwenden, um alle Nachrichten zu lesen und sie an einen Pool von Threads weiterzugeben. Obwohl dieser Ansatz die Verarbeitungsdurchsatz erh\u00f6ht, erh\u00f6ht er die Komplexit\u00e4t der Logik des Consumers und tr\u00e4gt nichts zur Widerstandsf\u00e4higkeit des Lesesystems bei. Wenn eine Instanz des Consumers aufgrund eines Stromausfalls oder \u00e4hnlicher Ereignisse ausf\u00e4llt, wird das Lesen eingestellt.<\/p>\n<p>Der kanonische Weg, dieses Problem in Kafka zu l\u00f6sen, besteht darin, b<i>e<\/i>reitere Partitions zu verwenden.<\/p>\n<h3>Partitionierung<\/h3>\n<p>\nPartitionen sind der Hauptmechanismus zur Parallelisierung des Lesens und zur Skalierung eines Topics \u00fcber die Durchsatzkapazit\u00e4t einer einzelnen Broker-Instanz hinaus. Um dies besser zu verstehen, betrachten wir eine Situation, in der es ein Topic mit zwei Partitionen gibt und ein Consumer sich f\u00fcr dieses Topic anmeldet (<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/en\/9g\/ct\/en9gct0o017cqp8buawguwlscty.png\">Abbildung 3-5<\/a><\/noindex>).<\/p>\n<p><img decoding=\"async\" alt=\"Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Mechanik des Nachrichtenaustauschs durch ActiveMQ und Kafka. Kapitel 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/cc766bf69af22698aacc3f1ac70b067f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 3-5. Ein Consumer liest aus mehreren Partitionen<\/i><\/p>\n<p>In diesem Szenario erh\u00e4lt der Consumer die Kontrolle \u00fcber die Zeiger, die seinem group_id in beiden Partitionen entsprechen, und beginnt, Nachrichten aus beiden Partitionen zu lesen.<br \/>\nWenn in dieses Thema ein zus\u00e4tzlicher Konsument f\u00fcr die gleiche group_id hinzugef\u00fcgt wird, weist Kafka eine der Partitionen vom ersten auf den zweiten Konsumenten neu zu. Danach liest jeder Konsument von einer Partition des Themas.<noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/8b\/a0\/um\/8ba0umn2yzr9yy3vztonhdfiub0.png\">Abbildung 3-6<\/a><\/noindex>).<\/p>\n<p>Um die Verarbeitung von Nachrichten parallel in 20 Threads zu gew\u00e4hrleisten, ben\u00f6tigen Sie mindestens 20 Partitionen. Wenn es weniger Partitionen gibt, haben Sie Konsumenten, die nichts zu tun haben, wie zuvor in der Diskussion \u00fcber monopolartige Konsumenten beschrieben.<\/p>\n<p><img decoding=\"async\" alt=\"Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Mechanik des Nachrichtenaustauschs durch ActiveMQ und Kafka. Kapitel 3. Kafka\" src=\"\/wp-content\/uploads\/2019\/09\/a3c4001e4a5b92d53b6f529b2633254a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 3-6. Zwei Konsumenten in derselben Konsumentengruppe lesen aus verschiedenen Partitionen.<\/i><\/p>\n<p>Dieses Schema reduziert die Komplexit\u00e4t der Arbeit des Kafka-Brokers erheblich im Vergleich zur Verteilung von Nachrichten, die zur Unterst\u00fctzung einer JMS-Warteschlange erforderlich ist. Hier m\u00fcssen Sie sich nicht um folgende Punkte k\u00fcmmern:<\/p>\n<ul>\n<li>Welcher Konsument die n\u00e4chste Nachricht erhalten soll, basierend auf der zyklischen (Round-Robin) Verteilung, der aktuellen Kapazit\u00e4t der Vorab-Puffer oder vorherigen Nachrichten (wie f\u00fcr JMS-Nachrichtengruppen).<\/li>\n<li>Welche Nachrichten an welche Konsumenten gesendet wurden und ob sie im Falle eines Fehlers erneut zugestellt werden m\u00fcssen.<\/li>\n<\/ul>\n<p>\nAlles, was ein Kafka-Broker tun muss, ist, Nachrichten sequenziell an den Consumer zu \u00fcbermitteln, wenn dieser sie anfordert.<\/p>\n<p>Die Anforderungen an die Parallelisierung der Lesevorg\u00e4nge und das erneute Versenden gescheiterter Nachrichten bleiben jedoch bestehen \u2013 die Verantwortung daf\u00fcr geht einfach vom Broker auf den Client \u00fcber. Das bedeutet, dass sie in Ihrem Code ber\u00fccksichtigt werden m\u00fcssen.<\/p>\n<h2>Nachrichten senden<\/h2>\n<p>\nDie Entscheidung, in welche Partition die Nachricht gesendet werden soll, liegt beim Produzenten dieser Nachricht. Um den Mechanismus zu verstehen, wie dies geschieht, m\u00fcssen wir zun\u00e4chst betrachtet, was genau wir tats\u00e4chlich senden.<\/p>\n<p>W\u00e4hrend wir in JMS eine Nachrichtenstruktur mit Metadaten (Kopfzeilen und Eigenschaften) und einem K\u00f6rper verwenden, der die Nutzlast (payload) enth\u00e4lt, ist in Kafka eine Nachricht <i>ein Paar \u201eSchl\u00fcssel-Wert\u201c<\/i>. Die Nutzlast der Nachricht wird als Wert (value) gesendet. Der Schl\u00fcssel hingegen wird haupts\u00e4chlich f\u00fcr die Partitionierung verwendet und muss einen <i>gesch\u00e4ftsspezifischen Schl\u00fcssel<\/i>enthalten, um verwandte Nachrichten in dieselbe Partition zu bringen.<\/p>\n<p>In Kapitel 2 haben wir das Szenario der Online-Wetten behandelt, bei dem verbundene Ereignisse der Reihe nach von einem einzelnen Verbraucher bearbeitet werden m\u00fcssen:<\/p>\n<ol>\n<li>Das Benutzerkonto ist eingerichtet.<\/li>\n<li>Geld wird dem Konto gutgeschrieben.<\/li>\n<li>Es wird eine Wette platziert, die Geld vom Konto abhebt.<\/li>\n<\/ol>\n<p>\nWenn jedes Ereignis eine Nachricht ist, die an ein Topic gesendet wird, dann ist der nat\u00fcrliche Schl\u00fcssel die Kontonummer.<br \/>\nWenn eine Nachricht mit der Kafka Producer API gesendet wird, wird sie der Partitionierungsfunktion \u00fcbergeben, die unter Ber\u00fccksichtigung der Nachricht und des aktuellen Zustands des Kafka-Clusters die ID der Partition zur\u00fcckgibt, in die die Nachricht gesendet werden soll. Diese Funktion ist in Java \u00fcber das Interface Partitioner implementiert.<\/p>\n<p>Dieses Interface sieht folgenderma\u00dfen aus:<\/p>\n<pre><code class=\"java\">interface Partitioner {\n    int partition(String topic,\n        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);\n}<\/code><\/pre>\n<p>\nDie Implementierung des Partitioner zur Bestimmung der Partition verwendet standardm\u00e4\u00dfig einen Hashing-Algorithmus f\u00fcr den Schl\u00fcssel oder eine Rundlaufmethode, wenn kein Schl\u00fcssel angegeben ist. Dieser Standardwert funktioniert in den meisten F\u00e4llen gut. In Zukunft m\u00f6chten Sie jedoch m\u00f6glicherweise Ihre eigene Implementierung schreiben.<\/p>\n<h3>Eigene Partitionierungsstrategie schreiben<\/h3>\n<p>\nLassen Sie uns ein Beispiel betrachten, bei dem Sie Metadaten zusammen mit der Payload einer Nachricht senden m\u00f6chten. Die Payload in unserem Beispiel ist eine Anweisung zur Einzahlung auf ein Spielkonto. Die Anweisung ist das, was wir sicherstellen m\u00f6chten, dass es bei der \u00dcbertragung nicht modifiziert wird, und wir m\u00f6chten sicher sein, dass nur ein vertrauensw\u00fcrdiges \u00fcbergeordnetes System diese Anweisung initiieren kann. In diesem Fall einigen sich absendende und empfangende Systeme auf die Verwendung einer Signatur zur Authentifizierung der Nachricht.<br \/>\nIm normalen JMS definieren wir einfach die Eigenschaft \u201eNachrichtensignatur\u201c und f\u00fcgen sie der Nachricht hinzu. Kafka bietet uns jedoch keinen Mechanismus zur \u00dcbertragung von Metadaten \u2013 nur Schl\u00fcssel und Wert.<\/p>\n<p>Da der Wert die Nutzlast einer Bank\u00fcberweisung (bank transfer payload) ist, deren Integrit\u00e4t wir wahren m\u00f6chten, bleibt uns nichts anderes \u00fcbrig, als die Datenstruktur f\u00fcr die Verwendung im Schl\u00fcssel zu definieren. Angenommen, wir ben\u00f6tigen eine Kontonummer f\u00fcr die Partitionierung, da alle Nachrichten, die sich auf das Konto beziehen, der Reihenfolge nach bearbeitet werden m\u00fcssen, dann entwerfen wir die folgende JSON-Struktur:<\/p>\n<pre><code class=\"json\">{\n  \"signature\": \"541661622185851c248b41bf0cea7ad0\",\n  \"accountId\": \"10007865234\"\n}<\/code><\/pre>\n<p>\nDa der Wert der Signatur je nach Nutzlast variieren wird, wird die Standard-Hashing-Strategie der Partitioner-Schnittstelle die zusammenh\u00e4ngenden Nachrichten nicht zuverl\u00e4ssig gruppieren. Daher m\u00fcssen wir unsere eigene Strategie schreiben, die diesen Schl\u00fcssel analysiert und den Wert accountId partitioniert.<\/p>\n<blockquote><p>Kafka beinhaltet Pr\u00fcfziffern zur Erkennung von Besch\u00e4digungen an Nachrichten in der Speicherung und bietet ein umfassendes Sicherheitsangebot. Trotzdem gibt es manchmal branchenspezifische Anforderungen, wie die oben angef\u00fchrten.<\/p><\/blockquote>\n<p>\nDie Benutzerstrategie zur Partitionierung sollte sicherstellen, dass alle verwandten Nachrichten in einer Partition zusammengef\u00fchrt werden. Auch wenn dies einfach erscheint, kann die Anforderung komplizierter werden, da die Reihenfolge der verwandten Nachrichten wichtig ist und wie fest die Anzahl der Partitionen im Thema ist.<\/p>\n<p>Die Anzahl der Partitionen in einem Thema kann sich im Laufe der Zeit \u00e4ndern, da sie hinzugef\u00fcgt werden k\u00f6nnen, wenn der Datenverkehr die urspr\u00fcnglichen Erwartungen \u00fcberschreitet. So k\u00f6nnen die Schl\u00fcssel der Nachrichten mit der Partition verbunden sein, in die sie urspr\u00fcnglich gesendet wurden, was einen Teil des Zustands impliziert, der zwischen den Instanzen des Produzenten verteilt werden muss.<\/p>\n<p>Ein weiterer Faktor, den es zu ber\u00fccksichtigen gilt, ist die gleichm\u00e4\u00dfige Verteilung der Nachrichten \u00fcber die Partitionen. Im Allgemeinen werden Schl\u00fcssel nicht gleichm\u00e4\u00dfig \u00fcber die Nachrichten verteilt, und Hash-Funktionen garantieren keine faire Verteilung der Nachrichten f\u00fcr eine kleine Menge von Schl\u00fcsseln.<br \/>\nEs ist wichtig zu beachten, dass, egal wie Sie sich entscheiden, die Nachrichten zu partitionieren, der Partitionierer m\u00f6glicherweise wiederverwendet werden muss.<\/p>\n<p>Betrachten wir die Anforderungen an die Datenreplikation zwischen Kafka-Clustern an verschiedenen geografischen Standorten. F\u00fcr diesen Zweck wird Kafka mit einem Befehlszeilenwerkzeug namens MirrorMaker geliefert, das zum Lesen von Nachrichten aus einem Cluster und deren \u00dcbertragung in ein anderes verwendet wird.<\/p>\n<p>MirrorMaker muss die Schl\u00fcssel des replizierten Themas verstehen, um die relative Reihenfolge der Nachrichten bei der Replikation zwischen den Clustern aufrechtzuerhalten, da die Anzahl der Partitionen f\u00fcr dieses Thema in beiden Clustern unterschiedlich sein kann.<\/p>\n<p>Benutzerdefinierte Partitionierungsstrategien kommen relativ selten vor, da die Standardmethoden Hashing oder Rundlauf in den meisten Szenarien erfolgreich funktionieren. Wenn jedoch strikte Reihenfolgenzusicherungen erforderlich sind oder wenn Sie Metadaten aus den Nutzlasten extrahieren m\u00fcssen, sollten Sie die Partitionierung n\u00e4her betrachten.<\/p>\n<p>Die Vorteile von Skalierbarkeit und Leistung in Kafka resultieren daraus, dass einige Aufgaben des traditionellen Brokers auf den Client \u00fcbertragen werden. In diesem Fall wird die Entscheidung getroffen, potenziell verwandte Nachrichten auf mehrere parallel arbeitende Verbraucher zu verteilen.<\/p>\n<blockquote><p>Auch JMS-Broker m\u00fcssen solche Anforderungen ber\u00fccksichtigen. Interessanterweise erfordert der Mechanismus zur Zustellung verwandter Nachrichten an denselben Verbraucher, der \u00fcber JMS Message Groups (eine Art Sticky Load Balancing (SLB)-Strategie) implementiert wird, dass der Sender die Nachrichten als verwandt kennzeichnet. Im Fall von JMS ist der Broker daf\u00fcr verantwortlich, diese Gruppe verwandter Nachrichten an einen von vielen Verbrauchern zu senden und die Eigentumsrechte an der Gruppe zu \u00fcbertragen, falls der Verbraucher ausf\u00e4llt.<\/p><\/blockquote>\n<p><\/p>\n<h2>Vereinbarungen \u00fcber Produzenten<\/h2>\n<p>\nPartitionierung ist nicht das einzige, was beim Senden von Nachrichten ber\u00fccksichtigt werden muss. Lassen Sie uns die Methoden send() der Klasse Producer in der Java-API betrachten:<\/p>\n<pre><code class=\"java\">Future  send(ProducerRecord  record);\nFuture  send(ProducerRecord  record, Callback callback);<\/code><\/pre>\n<p>\nEs sollte sofort angemerkt werden, dass beide Methoden ein Future zur\u00fcckgeben, was darauf hinweist, dass der Versand der Operation nicht sofort erfolgt. Dies f\u00fchrt dazu, dass die Nachricht (ProducerRecord) f\u00fcr jede aktive Partition in den Versandpuffer geschrieben wird und im Hintergrund von einem Thread in der Kafka-Client-Bibliothek an den Broker \u00fcbermittelt wird. Obwohl dies die Arbeit unglaublich schnell macht, bedeutet es, dass eine unvorsichtig geschriebene Anwendung Nachrichten verlieren kann, wenn ihr Prozess gestoppt wird.<\/p>\n<p>Wie immer gibt es einen Weg, die Versandoperation zuverl\u00e4ssiger zu gestalten, jedoch auf Kosten der Leistung. Die Gr\u00f6\u00dfe dieses Puffers kann auf 0 gesetzt werden, und der sendende Anwendungs-Thread muss warten, bis die \u00dcbertragung der Nachricht an den Broker abgeschlossen ist, wie folgt:<\/p>\n<pre><code class=\"java\">RecordMetadata metadata = producer.send(record).get();<\/code><\/pre>\n<p><\/p>\n<h2>Noch einmal zum Lesen von Nachrichten<\/h2>\n<p>\nDas Lesen von Nachrichten bringt zus\u00e4tzliche Schwierigkeiten mit sich, \u00fcber die nachgedacht werden muss. Im Gegensatz zur JMS-API, die einen Nachrichten-Poller (message listener) in Reaktion auf den Eingang einer Nachricht starten kann, fragt die <i>Consumer <\/i>Kafka nur ab (polling). Lassen Sie uns die verwendete Methode genauer betrachten <i>poll ()<\/i>, die daf\u00fcr verwendet wird:<\/p>\n<pre><code class=\"java\">ConsumerRecords  poll(long timeout);<\/code><\/pre>\n<p>\nDer R\u00fcckgabewert der Methode ist eine Containerstruktur, die mehrere Objekte enth\u00e4lt. <i>ConsumerRecord <\/i>aus potenziell mehreren Partitionen. <i>ConsumerRecord <\/i>ist selbst ein Halterobjekt f\u00fcr das Schl\u00fcssel-Wert-Paar mit entsprechenden Metadaten wie der Partition, aus der es stammt.<\/p>\n<p>Wie in Kapitel 2 besprochen, m\u00fcssen wir uns st\u00e4ndig dar\u00fcber im Klaren sein, was mit den Nachrichten nach ihrer erfolgreichen oder nicht erfolgreichen Verarbeitung geschieht, beispielsweise wenn der Client eine Nachricht nicht verarbeiten kann oder die Verarbeitung unterbricht. In JMS wurde dies \u00fcber den Best\u00e4tigungsmodus (acknowledgement mode) gehandhabt. Der Broker entfernt entweder die erfolgreich verarbeiteten Nachrichten oder liefert die nicht verarbeiteten oder fehlgeschlagenen Nachrichten erneut aus (vorausgesetzt, es wurden Transaktionen verwendet). <br \/>\nKafka funktioniert ganz anders. Nachrichten werden im Broker nach dem Lesen nicht gel\u00f6scht und die Verantwortung f\u00fcr das, was im Falle eines Fehlers geschieht, liegt beim Lese-Code selbst.<\/p>\n<p>Wie bereits erw\u00e4hnt, ist eine Consumer-Gruppe mit dem Offset im Log verbunden. Die Position im Log, die mit diesem Offset verkn\u00fcpft ist, entspricht der n\u00e4chsten Nachricht, die als Antwort ausgegeben wird. <i>poll ()<\/i>Der Zeitpunkt, an dem dieses Offset zunimmt, ist entscheidend f\u00fcr das Lesen.<\/p>\n<p>Zur\u00fcck zur zuvor besprochenen Lesemodell besteht die Verarbeitung einer Nachricht aus drei Phasen:<\/p>\n<ol>\n<li>Nachricht zum Lesen extrahieren.<\/li>\n<li>Nachricht verarbeiten.<\/li>\n<li>Nachricht best\u00e4tigen.<\/li>\n<\/ol>\n<p>\nDer Kafka-Consumer wird mit der Konfigurationsoption <i>enable.auto.commit<\/i>. Dies ist eine h\u00e4ufig verwendete Standardeinstellung, wie es oft bei Optionen mit dem Wort \u201eauto\u201c der Fall ist.<\/p>\n<p>Bis zu Kafka 0.10 sendete der Client, der dieses Flag nutzte, das Offset der letzten gelesenen Nachricht beim n\u00e4chsten Aufruf <i>poll ()<\/i> nach der Verarbeitung. Das bedeutete, dass bereits extrahierte (fetched) Nachrichten erneut verarbeitet werden konnten, wenn der Client sie bereits verarbeitet hatte, aber unerwartet vor dem Aufruf abgest\u00fcrzt ist. <i>poll ()<\/i>. Da der Broker keinen Zustand dar\u00fcber speichert, wie oft eine Nachricht gelesen wurde, wird der n\u00e4chste Verbraucher, der diese Nachricht abruft, nicht wissen, dass etwas Schlechtes passiert ist. Dieses Verhalten war pseudo-transaktional. Das Offset wurde nur bei erfolgreicher Verarbeitung der Nachricht festgeschrieben, aber wenn der Client die Arbeit unterbrach, sendete der Broker die gleiche Nachricht erneut an einen anderen Client. Dieses Verhalten entsprach der Garantie f\u00fcr die Zustellung von Nachrichten \u201e<i>mindestens einmal<\/i>\u201e.<\/p>\n<p>In Kafka 0.10 wurde der Client-Code so ge\u00e4ndert, dass das Commit periodisch von der Client-Bibliothek in \u00dcbereinstimmung mit der Einstellung <i>auto.commit.interval.ms<\/i>. Dieses Verhalten liegt irgendwo zwischen den Modi JMS AUTO_ACKNOWLEDGE und DUPS_OK_ACKNOWLEDGE. Bei der Verwendung von Auto-Commit konnten Nachrichten best\u00e4tigt werden, unabh\u00e4ngig davon, ob sie tats\u00e4chlich verarbeitet wurden \u2013 dies konnte bei einem langsamen Verbraucher auftreten. Wenn der Verbraucher unterbrochen wurde, wurden die Nachrichten vom n\u00e4chsten Verbraucher ab der best\u00e4tigten Position abgerufen, was zum Verlust einer Nachricht f\u00fchren konnte. In diesem Fall hat Kafka die Nachrichten nicht verloren, der Lese-Code hat sie einfach nicht verarbeitet.<\/p>\n<p>Dieser Modus weist dieselben Perspektiven auf wie in der Version 0.9: Nachrichten k\u00f6nnen verarbeitet werden, aber im Falle eines Fehlers k\u00f6nnte der Offset nicht best\u00e4tigt werden, was potenziell zu doppelter Zustellung f\u00fchren kann. Je mehr Nachrichten Sie beim Abruf <i>poll ()<\/i>, desto gr\u00f6\u00dfer wird dieses Problem.<\/p>\n<p>Wie im Abschnitt \u00bbNachrichten aus der Warteschlange lesen\u00ab auf Seite 21 besprochen, gibt es im Nachrichtenaustausch kein Konzept der einmaligen Zustellung von Nachrichten, wenn man die Fehlermodi ber\u00fccksichtigt.<\/p>\n<p>In Kafka gibt es zwei M\u00f6glichkeiten, einen Offset zu speichern (commit): automatisch und manuell. In beiden F\u00e4llen k\u00f6nnen Nachrichten mehrfach verarbeitet werden, wenn die Nachricht bereits bearbeitet wurde, aber ein Fehler aufgetreten ist, bevor der Commit durchgef\u00fchrt wurde. Es kann auch vorkommen, dass eine Nachricht gar nicht verarbeitet wird, wenn der Commit im Hintergrund erfolgt ist und Ihr Code bereits beendet wurde, bevor er mit der Verarbeitung begonnen hat (vielleicht in Kafka 0.9 und fr\u00fcheren Versionen).<\/p>\n<p>Sie k\u00f6nnen den Commit-Prozess manuell im Kafka-Consumer-API steuern, indem Sie den Parameter <i>enable.auto.commit<\/i> auf false setzen und explizit eine der folgenden Methoden aufrufen:<\/p>\n<pre><code class=\"java\">void commitSync();\nvoid commitAsync();<\/code><\/pre>\n<p>\nWenn Sie darauf abzielen, eine Nachricht \"mindestens einmal\" zu verarbeiten, m\u00fcssen Sie den Offset manuell mit <i>commitSync()<\/i>committieren, indem Sie diesen Befehl sofort nach der Verarbeitung der Nachrichten ausf\u00fchren.<\/p>\n<p>Diese Methoden erm\u00f6glichen es nicht, Nachrichten zu best\u00e4tigen (acknowledged), bevor sie verarbeitet werden, aber sie tun nichts, um potenzielle doppelte Verarbeitung zu vermeiden und sorgen gleichzeitig f\u00fcr ein Gef\u00fchl von Transaktionsf\u00e4higkeit. In Kafka gibt es keine Transaktionen. Der Client hat nicht die M\u00f6glichkeit, Folgendes durchzuf\u00fchren:<\/p>\n<ul>\n<li>Rollback von fehlgeschlagenen Nachrichten automatisch durchf\u00fchren. Konsumenten m\u00fcssen selbst Ausnahmen behandeln, die durch fehlerhafte Payloads und Backend-Ausf\u00e4lle entstehen, da sie sich nicht auf die erneute Zustellung von Nachrichten durch den Broker verlassen k\u00f6nnen.<\/li>\n<li>Nachrichten in mehrere Themen im Rahmen einer einzigen atomaren Operation senden. Wie wir gleich sehen werden, kann die Kontrolle \u00fcber verschiedene Themen und Partitionen auf verschiedenen Maschinen im Kafka-Cluster liegen, die keine Koordination der Transaktionen beim Versand vornehmen. Zum Zeitpunkt des Verfassens dieses Artikels wurde bereits Arbeit geleistet, um dies mit KIP-98 m\u00f6glich zu machen.<\/li>\n<li>Das Lesen einer Nachricht aus einem Thema mit dem Senden einer anderen Nachricht in ein anderes Thema verkn\u00fcpfen. Auch hier basiert die Architektur von Kafka auf vielen unabh\u00e4ngigen Maschinen, die als ein Bus fungieren, und es werden keine Versuche unternommen, dies zu verbergen. Beispielsweise gibt es keine API-Komponenten, die dies erm\u00f6glichen w\u00fcrden. <i>Konsument <\/i>und <i>Produzent <\/i>in der Transaktion. In JMS wird dies durch ein Objekt sichergestellt, <i>Wir \u00f6ffnen das Programm Putty, w\u00e4hlen die Kategorie<\/i>aus dem <i>MessageProducers erstellt werden. <\/i>und <i>MessageConsumers<\/i>.<\/li>\n<\/ul>\n<p>\nWenn wir uns nicht auf Transaktionen verlassen k\u00f6nnen, wie k\u00f6nnen wir dann eine Semantik gew\u00e4hrleisten, die n\u00e4her an dem liegt, was traditionelle Nachrichtensysteme bieten?<\/p>\n<p>Falls die M\u00f6glichkeit besteht, dass der Consumer-Offset steigen kann, bevor die Nachricht verarbeitet wurde, beispielsweise w\u00e4hrend eines Consumer-Ausfalls, hat der Consumer keine M\u00f6glichkeit zu erfahren, ob seine Consumer-Gruppe Nachrichten \u00fcbersprungen hat, wenn ihm eine Partition zugewiesen wird. Eine der Strategien besteht daher darin, den Offset auf die vorherige Position zur\u00fcckzuspulen. Die Kafka-Consumer-API bietet folgende Methoden daf\u00fcr an:<\/p>\n<pre><code class=\"java\">void seek(TopicPartition partition, long offset);\nvoid seekToBeginning(Collection  partitions);<\/code><\/pre>\n<p>\nMethode <i>seek ()<\/i> kann in Verbindung mit der Methode verwendet werden <br \/>\n<i>offsetsForTimes (Map timestampsToSearch)<\/i> um auf einen bestimmten Zustand in der Vergangenheit zur\u00fcckzuspulen.<\/p>\n<p>Implizit bedeutet diese Herangehensweise, dass es sehr wahrscheinlich ist, dass einige Nachrichten, die bereits verarbeitet wurden, erneut gelesen und verarbeitet werden. Um dies zu vermeiden, k\u00f6nnen wir idempotentes Lesen verwenden, wie in Kapitel 4 beschrieben, um zuvor gesehene Nachrichten zu verfolgen und Duplikate auszuschlie\u00dfen.<\/p>\n<p>Alternativ kann der Code Ihres Verbrauchers einfach sein, wenn der Verlust oder die Duplizierung von Nachrichten akzeptabel ist. Wenn wir Anwendungsf\u00e4lle betrachten, f\u00fcr die Kafka typischerweise verwendet wird, wie z.B. die Verarbeitung von Ereignisprotokollen, Metriken, Klick-Tracking usw., verstehen wir, dass der Verlust einzelner Nachrichten wahrscheinlich keine signifikanten Auswirkungen auf die umgebenden Anwendungen hat. In solchen F\u00e4llen sind Standardwerte durchaus akzeptabel. Andererseits, wenn Ihre Anwendung Zahlungen verarbeiten muss, sollten Sie jedes einzelne Nachricht sorgf\u00e4ltig behandeln. Alles h\u00e4ngt vom Kontext ab.<\/p>\n<p>Pers\u00f6nliche Erfahrungen zeigen, dass mit zunehmender Nachrichtenintensit\u00e4t der Wert jeder einzelnen Nachricht sinkt. Nachrichten in gro\u00dfem Umfang sind in der Regel dann wertvoll, wenn sie aggregiert betrachtet werden.<\/p>\n<h2>Hohe Verf\u00fcgbarkeit (High Availability)<\/h2>\n<p>\nDer Ansatz von Kafka zur hohen Verf\u00fcgbarkeit unterscheidet sich grundlegend vom Ansatz von ActiveMQ. Kafka ist auf horizontal skalierbaren Clustern aufgebaut, in denen alle Broker-Instanzen Nachrichten gleichzeitig empfangen und verteilen.<\/p>\n<p>Ein Kafka-Cluster besteht aus mehreren Broker-Instanzen, die auf unterschiedlichen Servern arbeiten. Kafka wurde entwickelt, um auf herk\u00f6mmlicher, dedizierter Hardware zu funktionieren, wobei jeder Knoten \u00fcber seinen eigenen, zugewiesenen Speicher verf\u00fcgt. Die Verwendung von Netzwerk-Speichern (SAN) wird nicht empfohlen, da mehrere Rechenknoten um Zeitintervalle im Speicher konkurrieren und Konflikte verursachen k\u00f6nnen.<i>\u00c4<\/i>e Intervalle im Speicher und Konflikte verursachen.<\/p>\n<p>Kafka ist <i>stets aktiv<\/i> System. Viele gro\u00dfe Nutzer von Kafka schalten ihre Cluster niemals aus, und die Software sorgt st\u00e4ndig f\u00fcr Aktualisierungen durch sequenzielles Neustarten. Dies wird durch die Gew\u00e4hrleistung der Kompatibilit\u00e4t mit der vorherigen Version f\u00fcr Nachrichten und Interaktionen zwischen Brokern erreicht.<\/p>\n<p>Die Broker sind mit dem Server-Cluster verbunden <noindex><a rel=\"nofollow\" href=\"http:\/\/zookeeper.apache.org\">ZooKeeper<\/a><\/noindex>, der als Konfigurationsdatenregister fungiert und zur Koordination der Rollen jedes Brokers verwendet wird. ZooKeeper selbst ist ein verteiltes System, das hohe Verf\u00fcgbarkeit durch die Replikation von Informationen gew\u00e4hrleistet, indem es einen <i>Quorum<\/i>.<\/p>\n<p>Im einfachsten Fall wird ein Topic im Kafka-Cluster mit den folgenden Eigenschaften erstellt:<\/p>\n<ul>\n<li>Anzahl der Partitionen. Wie bereits erw\u00e4hnt, h\u00e4ngt der genaue Wert, der hier verwendet wird, vom gew\u00fcnschten Grad an parallelem Lesen ab.<\/li>\n<li>Der Replikationsfaktor bestimmt, wie viele Instanzen des Brokers im Cluster die Protokolle f\u00fcr diese Partition enthalten m\u00fcssen.<\/li>\n<\/ul>\n<p>\nMit ZooKeepers zur Koordination versucht Kafka, neue Partitionen gerecht zwischen den Broker im Cluster zu verteilen. Dies geschieht durch eine Instanz, die die Rolle des Controllers \u00fcbernimmt.<\/p>\n<p>Zur Laufzeit <i>f\u00fcr jede Partition des Themas<\/i> <i>Controller <\/i>weist Brokern Rollen zu <i>als F\u00fchrer <\/i>(Leader, Master, Vorreiter) und <i>Nachfolgern <\/i>(Followers, Sklaven, Untergeordneten). Der Broker, der als F\u00fchrer f\u00fcr eine bestimmte Partition fungiert, ist verantwortlich f\u00fcr die Annahme aller Nachrichten, die von Produzenten an ihn gesendet werden, und die Verbreitung dieser Nachrichten an Konsumenten. Beim Senden von Nachrichten an die Partition eines Themas werden diese auf alle Knoten des Brokers, die als Nachfolger f\u00fcr diese Partition fungieren, repliziert. Jeder Knoten, der Protokolle f\u00fcr die Partition enth\u00e4lt, wird als <i>Replik<\/i>bezeichnet. Ein Broker kann als F\u00fchrer f\u00fcr einige Partitionen und als Nachfolger f\u00fcr andere agieren.<\/p>\n<p>Der Nachfolger, der alle Nachrichten enth\u00e4lt, die beim F\u00fchrer gespeichert sind, wird als <i>synchronisierte Replik<\/i> (in einem synchronisierten Zustand befindliche, in-sync Replica). Wenn der Broker, der als Leader f\u00fcr die Partition fungiert, ausf\u00e4llt, kann jeder Broker, der sich in einem aktuellen oder synchronisierten Zustand f\u00fcr diese Partition befindet, die F\u00fchrungsrolle \u00fcbernehmen. Dies ist ein \u00e4u\u00dferst robuster Entwurf.<\/p>\n<p>Ein Teil der Konfiguration des Producers ist der Parameter <i>acks<\/i>, der definiert, wie viele Replikate den Erhalt einer Nachricht best\u00e4tigen m\u00fcssen, bevor der Anwendungsstream mit dem Senden fortf\u00e4hrt: 0, 1 oder alle. Wenn der Wert gesetzt ist <i>all<\/i>, wird der Leader beim Erhalt der Nachricht eine Best\u00e4tigung (confirmation) an den Producer senden, sobald er die Best\u00e4tigungen (acknowledgements) der Aufzeichnung von mehreren Replikaten (einschlie\u00dflich sich selbst) erhalten hat, die durch die Einstellung des Themas <i>min.insync.replicas<\/i> vorgeschrieben sind (Standardwert 1). Wenn die Nachricht nicht erfolgreich repliziert werden kann, wird der Producer eine Ausnahme f\u00fcr die Anwendung ausl\u00f6sen (<i>NotEnoughReplicas<\/i> oder <i>NotEnoughReplicasAfterAppend<\/i>).<\/p>\n<p>In einer typischen Konfiguration wird ein Thema mit einem Replikationsfaktor von 3 erstellt (1 Leader, 2 Follower f\u00fcr jede Partition) und der Parameter <i>min.insync.replicas<\/i> wird auf 2 gesetzt. In diesem Fall kann der Cluster erlauben, dass einer der Broker, die die Partition des Themas verwalten, ohne Einfluss auf die Clientanwendungen abgeschaltet wird.<\/p>\n<p>Das bringt uns zur\u00fcck zu dem bereits bekannten Kompromiss zwischen Leistung und Zuverl\u00e4ssigkeit. Die Replikation erfolgt durch zus\u00e4tzliche Wartezeiten f\u00fcr Best\u00e4tigungen von den Folgesystemen. Da sie jedoch parallel erfolgt, hat die Replikation, mindestens auf drei Knoten, die gleiche Leistung wie auf zwei (ohne die erh\u00f6hte Nutzung der Netzbandbreite zu ber\u00fccksichtigen).<\/p>\n<p>Durch die Verwendung dieses Replikationsschemas umgeht Kafka geschickt die Notwendigkeit, jede Nachricht physisch auf die Festplatte mit der Operation <i>sync()<\/i>. Jede von einem Producer gesendete Nachricht wird im Partition-Log aufgezeichnet, aber wie in Kapitel 2 besprochen, erfolgt die initiale Speicherung in einer Datei im Puffer des Betriebssystems. Wenn diese Nachricht auf eine andere Kafka-Instanz repliziert wird und sich im Speicher dieser Instanz befindet, bedeutet der Verlust des Leaders nicht, dass die Nachricht selbst verloren geht \u2013 sie kann von einer synchronen Replik \u00fcbernommen werden.<br \/>\nVerzicht auf die Notwendigkeit, eine Operation auszuf\u00fchren <i>sync()<\/i> bedeutet, dass Kafka Nachrichten in dem Tempo empfangen kann, in dem es sie im Speicher aufzeichnen kann. Und umgekehrt, je l\u00e4nger man das Flushen des Speichers auf die Festplatte vermeiden kann, desto besser. Aus diesem Grund ist es nicht ungew\u00f6hnlich, dass Kafka-Broker 64 GB oder mehr RAM zugewiesen bekommen. Diese Speichernutzung erm\u00f6glicht es einem Kafka-Exemplar, Geschwindigkeiten zu erreichen, die viele Tausend Mal schneller sind als bei traditionellen Message Brokern.<\/p>\n<p>Kafka kann auch f\u00fcr den Einsatz von Operationen konfiguriert werden <i>sync()<\/i> zu Nachrichtenpaketen. Da alles in Kafka auf die Arbeit mit Paketen ausgerichtet ist, funktioniert dies in der Tat ziemlich gut f\u00fcr viele Anwendungsf\u00e4lle und ist ein n\u00fctzliches Werkzeug f\u00fcr Nutzer, die sehr starke Garantien ben\u00f6tigen. Der Gro\u00dfteil der reinen Leistung von Kafka h\u00e4ngt mit den Nachrichten zusammen, die als Pakete an den Broker gesendet werden, und damit, dass diese Nachrichten in aufeinanderfolgen Bl\u00f6cken vom Broker gelesen werden. <noindex><a rel=\"nofollow\" href=\"http:\/\/www.linuxjournal.com\/article\/6345\">Zero-Copy<\/a><\/noindex> Operationen (Vorg\u00e4nge, bei denen keine Daten von einem Speicherbereich in einen anderen kopiert werden). Letzteres ist ein gro\u00dfer Gewinn in Bezug auf Leistung und Ressourcen und ist nur durch die zugrunde liegende Datenstruktur des Logs m\u00f6glich, die das Partitionierungsschema bestimmt.<\/p>\n<p>Im Kafka-Cluster ist eine weitaus h\u00f6here Leistung m\u00f6glich als bei der Verwendung eines einzelnen Kafka-Brokers, da die Topic-Partitionen horizontal \u00fcber viele separate Maschinen skalierbar sind.<\/p>\n<h2>Ergebnisse<\/h2>\n<p>\nIn diesem Kapitel haben wir untersucht, wie die Architektur von Kafka die Beziehungen zwischen Clients und Brokern neu definiert, um einen unglaublich stabilen Messaging-Kanal zu gew\u00e4hrleisten, der eine weit \u00fcberlegene Kapazit\u00e4t im Vergleich zu herk\u00f6mmlichen Messaging-Brokern bietet. Wir haben die Funktionen besprochen, die daf\u00fcr verwendet werden, und einen kurzen \u00dcberblick \u00fcber die Architektur der Anwendungen gegeben, die diese Funktionen erm\u00f6glichen. Im n\u00e4chsten Kapitel werden wir uns mit den allgemeinen Herausforderungen befassen, die Messaging-basierte Anwendungen bew\u00e4ltigen m\u00fcssen, und Strategien zu deren L\u00f6sung diskutieren. Wir schlie\u00dfen das Kapitel mit \u00dcberlegungen zur Handhabung von Messaging-Technologien insgesamt ab, sodass Sie deren Eignung f\u00fcr Ihre Anwendungsf\u00e4lle besser einsch\u00e4tzen k\u00f6nnen.<\/p>\n<p>Vorheriger \u00fcbersetzter Teil: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466385\/\">Verst\u00e4ndnis von Nachrichtenbrokern. Untersuchung der Nachrichten\u00fcbertragung mit ActiveMQ und Kafka. Kapitel 1<\/a><\/noindex><\/p>\n<p><b> \u00dcbersetzung abgeschlossen: <noindex><a rel=\"nofollow\" href=\"http:\/\/tele.gg\/middle_java\">tele.gg\/middle_java<\/a><\/noindex><\/b><\/p>\n<p><i>Fortsetzung folgt\u2026<\/i><\/p>\n<p class=\"for_users_only_msg\">Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Bitte melden Sie sich an.<\/a><\/noindex>Sind Sie an Contour interessiert?<\/p>\n<h2 class=\"default-block__polling-title\">Wird Kafka in Ihrer Organisation eingesetzt?<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Ja<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Nein<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Wurde fr\u00fcher verwendet, jetzt nicht mehr<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Planen wir einzusetzen<\/p>\n<\/li>\n<\/ul>\n<p>    38 Nutzer haben abgestimmt. 8 Nutzer haben sich enthalten.<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466585\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#8217;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c: \u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0413\u041b\u0410\u0412\u0410 3 Kafka Kafka \u0431\u044b\u043b\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u0430 \u0432 LinkedIn \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0431\u043e\u0439\u0442\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u0438 [&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-38172","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#039;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c: \u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0413\u041b\u0410\u0412\u0410 3 Kafka Kafka \u0431\u044b\u043b\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u0430 \u0432 LinkedIn \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0431\u043e\u0439\u0442\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u0438\" \/>\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\/de\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 3. Kafka | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O&#039;Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c: \u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0413\u041b\u0410\u0412\u0410 3 Kafka Kafka \u0431\u044b\u043b\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u0430 \u0432 LinkedIn \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0431\u043e\u0439\u0442\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u0438\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka\" \/>\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-10-31T19:22:05+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:22:05+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\udd47Verst\u00e4ndnis von Nachrichtensystemen. Untersuchung der Mechanik des Nachrichtenaustausches mithilfe von ActiveMQ und Kafka. Kapitel 3. Kafka | ProHoster","description":"Fortsetzung der \u00dcbersetzung eines kleinen Buches: \u201eUnderstanding Message Brokers\u201c, Autor: Jakub Korab, Verlag: O'Reilly Media, Inc., Erscheinungsdatum: Juni 2017, ISBN: 9781492049296. Fr\u00fchere \u00fcbersetzte Teile: Verst\u00e4ndnis von Nachrichtensystemen. Untersuchung der Mechanik des Nachrichtenaustausches mithilfe von ActiveMQ und Kafka. Kapitel 1. Einleitung KAPITEL 3 Kafka Kafka wurde bei LinkedIn entwickelt, um einige Einschr\u00e4nkungen traditioneller Nachrichtensysteme zu umgehen und","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\udd47\u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 3. Kafka | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0439 \u043a\u043d\u0438\u0433\u0438: \u00abUnderstanding Message Brokers\u00bb, \u0430\u0432\u0442\u043e\u0440: Jakub Korab, \u0438\u0437\u0434\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u043e: O'Reilly Media, Inc., \u0434\u0430\u0442\u0430 \u0438\u0437\u0434\u0430\u043d\u0438\u044f: June 2017, ISBN: 9781492049296. \u041f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0430\u044f \u043f\u0435\u0440\u0435\u0432\u0435\u0434\u0435\u043d\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c: \u041f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439. \u0418\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0438 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u043f\u043e\u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e\u043c ActiveMQ \u0438 Kafka. \u0413\u043b\u0430\u0432\u0430 1. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0413\u041b\u0410\u0412\u0410 3 Kafka Kafka \u0431\u044b\u043b\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u0430 \u0432 LinkedIn \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043e\u0431\u043e\u0439\u0442\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u044f \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0431\u0440\u043e\u043a\u0435\u0440\u043e\u0432 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u0438","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ponimanie-brokerov-soobshhenij-izuchenie-mehaniki-obmena-soobshheniyami-posredstvom-activemq-i-kafka-glava-3-kafka","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-10-31T19:22:05+00:00","article:modified_time":"2019-10-31T19:22:05+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38172","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-23 20:46:00","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:34:26","updated":"2026-01-23 20:46:00"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38172","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=38172"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38172\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=38172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=38172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=38172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}