Das Buch "Apache Kafka. Stream-Verarbeitung und Datenanalyse “

Während der Arbeit einer Unternehmensanwendung werden Daten generiert: Dies sind Protokolldateien, Metriken, Informationen zur Benutzeraktivität, ausgehende Nachrichten usw. Die ordnungsgemäße Bearbeitung all dieser Daten ist nicht weniger wichtig als die Daten selbst. Wenn Sie ein Architekt, Entwickler oder Diplomingenieur sind, der solche Probleme lösen möchte, aber noch nicht mit Apache Kafka vertraut ist, lernen Sie in diesem wunderbaren Buch, wie Sie mit dieser kostenlosen Streaming-Plattform arbeiten, mit der Sie Datenwarteschlangen in Echtzeit verarbeiten können.

Für wen ist dieses Buch?

„Apache Kafka. Stream-Verarbeitung und Datenanalyse “wurde für Entwickler geschrieben, die die Kafka-API in ihrer Arbeit verwenden, sowie für Prozessingenieure (auch SRE, DevOps oder Systemadministratoren genannt), die an der Installation, Konfiguration, Konfiguration und Überwachung ihres Betriebs im industriellen Betrieb beteiligt sind. Wir haben auch Datenarchitekten und Analytiker nicht vergessen - diejenigen, die für das Design und die Erstellung der gesamten Dateninfrastruktur des Unternehmens verantwortlich sind. Einige Kapitel, insbesondere 3, 4 und 11, richten sich an Java-Entwickler. Um sie zu verstehen, ist es wichtig, dass der Leser mit den Grundlagen der Java-Programmiersprache vertraut ist, einschließlich Themen wie Ausnahmebehandlung und Wettbewerb.

In anderen Kapiteln, insbesondere in den Kapiteln 2, 8, 9 und 10, wird davon ausgegangen, dass der Leser Erfahrung mit Linux hat und mit der Konfiguration des Linux-Netzwerks und -Speichers vertraut ist. Der Rest der Buch- und Softwarearchitekturen von Kafka wird allgemeiner behandelt, sodass für die Leser keine besonderen Kenntnisse erforderlich sind.

Eine weitere Kategorie von Personen, die an diesem Buch interessiert sein könnten, sind Manager und Architekten, die nicht direkt mit Kafka zusammenarbeiten, sondern mit denen, die damit arbeiten. Es ist nicht weniger wichtig, dass sie verstehen, welche Garantien die Plattform bietet und welche Kompromisse ihre Untergebenen und Kollegen bei der Erstellung von Kafka-basierten Systemen eingehen müssen. Dieses Buch ist nützlich für Manager, die ihre Mitarbeiter für die Arbeit mit Kafka schulen oder sicherstellen möchten, dass das Entwicklungsteam über die erforderlichen Informationen verfügt.

Kapitel 2. Kafka installieren

Apache Kafka ist eine Java-Anwendung, die auf vielen Betriebssystemen ausgeführt werden kann, einschließlich Windows, MacOS, Linux und anderen. In diesem Kapitel konzentrieren wir uns auf die Installation von Kafka unter Linux, da diese Plattform am häufigsten auf diesem Betriebssystem installiert wird. Linux ist auch das empfohlene Betriebssystem für die allgemeine Kafka-Bereitstellung. Informationen zur Installation von Kafka unter Windows und MacOS finden Sie in Anhang A.

Installieren Sie Java

Vor der Installation von ZooKeeper oder Kafka müssen Sie die Java-Umgebung installieren und konfigurieren. Es wird empfohlen, Java 8 zu verwenden. Dies kann eine Version sein, die entweder in Ihrem Betriebssystem enthalten ist oder direkt von java.com heruntergeladen wird. Obwohl ZooKeeper und Kafka mit der Java Runtime Edition zusammenarbeiten, ist es bequemer, bei der Entwicklung von Dienstprogrammen und Anwendungen das vollständige Java Development Kit (JDK) zu verwenden. Bei diesen Installationsschritten wird davon ausgegangen, dass JDK Version 8.0.51 im Verzeichnis /usr/java/jdk1.8.0_51 installiert ist.

Installieren Sie ZooKeeper

Apache Kafka verwendet ZooKeeper, um Metadaten zum Kafka-Cluster sowie Details zu Consumer-Clients zu speichern (Abb. 2.1). Obwohl ZooKeeper auch mit Skripten gestartet werden kann, die in der Kafka-Distribution enthalten sind, ist die Installation der Vollversion des ZooKeeper-Repositorys aus der Distribution sehr einfach.


Kafka wurde gründlich mit der stabilen Version 3.4.6 des ZooKeeper-Repositorys getestet, die von apache.org heruntergeladen werden kann.

Standalone-Server

Das folgende Beispiel zeigt die Installation von ZooKeeper mit den Grundeinstellungen im Verzeichnis / usr / local / zookeeper und das Speichern der Daten im Verzeichnis / var / lib / zookeeper:

# tar -zxf zookeeper-3.4.6.tar.gz # mv zookeeper-3.4.6 /usr/local/zookeeper # mkdir -p /var/lib/zookeeper # cat > /usr/local/zookeeper/conf/zoo.cfg << EOF > tickTime=2000 > dataDir=/var/lib/zookeeper > clientPort=2181 > EOF # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # 

Jetzt können Sie überprüfen, ob ZooKeeper offline arbeiten soll, indem Sie eine Verbindung zum Client-Port herstellen und den aus vier Buchstaben bestehenden Befehl srvr senden:

 # telnet localhost 2181 Trying ::1... Connected to localhost. Escape character is '^]'. srvr Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT Latency min/avg/max: 0/0/0 Received: 1 Sent: 0 Connections: 1 Outstanding: 0 Zxid: 0x0 Mode: standalone Node count: 4 Connection closed by foreign host. # 

ZooKeeper Ensemble

Der ZooKeeper-Cluster wird als Ensemble bezeichnet. Aufgrund der Art des Algorithmus selbst wird empfohlen, dass das Ensemble eine ungerade Anzahl von Servern enthält, z. B. 3, 5 usw., damit ZooKeeper auf Anfragen reagieren kann, muss die Mehrheit der Ensemblemitglieder funktionieren (Quorum). Dies bedeutet, dass ein Ensemble aus drei Knoten mit einem freien Knoten arbeiten kann. Wenn das Ensemble drei Knoten hat, kann es zwei geben.

Um den Betrieb von ZooKeeper-Servern im Ensemble zu konfigurieren, müssen sie eine einzige Konfiguration mit einer Liste aller Server haben, und jeder Server im Datenverzeichnis muss eine myid-Datei mit der Kennung dieses Servers haben. Wenn die Hosts im Ensemble zoo1.example.com, zoo2.example.com und zoo3.example.com heißen, sieht die Konfigurationsdatei möglicherweise folgendermaßen aus:

 tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 initLimit=20 syncLimit=5 server.1=zoo1.example.com:2888:3888 server.2=zoo2.example.com:2888:3888 server.3=zoo3.example.com:2888:3888 

In dieser Konfiguration gibt initLimit die Zeit an, die Slave-Knoten mit dem Master verbinden können. Der syncLimit-Wert begrenzt die Verzögerung der Slave-Knoten vom Master. Beide Werte werden in tickTime-Einheiten angegeben, d. H. InitLimit = 20 · 2000 ms = 40 s. Die Konfiguration listet auch alle Ensemble-Server auf. Sie haben das Format server.X = Hostname: PeerPort: LeaderPort mit den folgenden Parametern:

• X ist die Serverkennung. Es muss eine Ganzzahl sein, aber die Anzahl darf nicht von Null und nicht sequentiell sein.
• Hostname - Hostname oder Server-IP-Adresse;
• PeerPort - TCP-Port, über den Ensemble-Server miteinander kommunizieren.
• LeaderPort - TCP-Port, über den der Host ausgewählt wird.

Es reicht aus, dass Clients über den clientPort-Port eine Verbindung zum Ensemble herstellen können, die Ensemblemitglieder müssen jedoch in der Lage sein, an allen drei Ports Nachrichten miteinander auszutauschen.

Zusätzlich zu einer einzelnen Konfigurationsdatei muss jeder Server im Verzeichnis dataDir eine myid-Datei haben. Es sollte die Server-ID enthalten, die der in der Konfigurationsdatei angegebenen entspricht. Nachdem Sie diese Schritte ausgeführt haben, können Sie die Server starten und sie interagieren im Ensemble miteinander.

Kafka Broker installieren

Nachdem Sie die Konfiguration von Java und ZooKeeper abgeschlossen haben, können Sie mit der Installation von Apache Kafka fortfahren. Die neueste Version von Apache Kafka kann unter kafka.apache.org/downloads.html heruntergeladen werden .

Installieren Sie im folgenden Beispiel die Kafka-Plattform im Verzeichnis / usr / local / kafka, konfigurieren Sie sie für die Verwendung des zuvor gestarteten ZooKeeper-Servers und speichern Sie die Nachrichtenprotokollsegmente im Verzeichnis / tmp / kafka-logs:

 # tar -zxf kafka_2.11-0.9.0.1.tgz # mv kafka_2.11-0.9.0.1 /usr/local/kafka # mkdir /tmp/kafka-logs # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

Nach dem Start des Kafka-Brokers können Sie dessen Funktion testen, indem Sie einfache Vorgänge mit dem Cluster ausführen, einschließlich Erstellen eines Testthemas, Generieren von Nachrichten und Konsumieren von Nachrichten.

Erstellen und Überprüfen von Threads:

 # /usr/local/kafka/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test Created topic "test". # /usr/local/kafka/bin/kafka-topics.sh --zookeeper localhost:2181 --describe --topic test Topic:test PartitionCount:1 ReplicationFactor:1 Configs: Topic: test Partition: 0 Leader: 0 Replicas: 0 Isr: 0 # 

Nachrichten für das Testthema generieren:

 # /usr/local/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test Test Message 1 Test Message 2 ^D # 

Nachrichten aus dem Testthema verbrauchen:

 # /usr/local/kafka/bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning Test Message 1 Test Message 2 ^C Consumed 2 messages # 

Brokerkonfiguration

Das mit der Kafka-Distribution gelieferte Beispiel für die Brokerkonfiguration eignet sich gut für einen Testlauf eines eigenständigen Servers, reicht jedoch für die meisten Installationen nicht aus. Es gibt viele Kafka-Konfigurationsoptionen, die alle Aspekte der Installation und Konfiguration regeln. Sie können die Standardwerte für viele von ihnen beibehalten, da sie sich auf die Nuancen beim Einrichten eines Kafka-Brokers beziehen, die erst anwendbar sind, wenn Sie mit einem bestimmten Szenario arbeiten, in dem sie verwendet werden müssen.

Grundlegende Brokereinstellungen

Es gibt verschiedene Einstellungen des Kafka-Brokers, die Sie bei der Bereitstellung der Plattform in einer beliebigen Umgebung berücksichtigen sollten, mit Ausnahme eines eigenständigen Brokers auf einem separaten Server. Diese Parameter beziehen sich auf die Haupteinstellungen des Brokers. Die meisten müssen geändert werden, damit der Broker in einem Cluster mit anderen Brokern zusammenarbeiten kann.

broker.id

Jeder Kafka-Broker muss eine Ganzzahl-ID haben, die durch den Parameterbroker.id angegeben wird. Standardmäßig ist dieser Wert 0, kann aber eine beliebige Zahl sein. Die Hauptsache ist, dass es sich nicht innerhalb desselben Kafka-Clusters wiederholt. Die Wahl der Nummer kann beliebig sein und kann zur Vereinfachung der Wartung bei Bedarf von einem Broker auf einen anderen übertragen werden. Es ist wünschenswert, dass diese Nummer irgendwie mit dem Host verbunden ist, dann wird die Korrespondenz von Broker-IDs zu Hosts mit Tracking transparenter. Wenn Ihre Hostnamen beispielsweise eindeutige Nummern enthalten (z. B. host1.example.com, host2.example.com usw.), sind diese Nummern eine gute Wahl für Broker.id-Werte.

Hafen

Eine typische Konfigurationsdatei startet Kafka mit einem Listener am TCP-Port 9092. Dieser Port kann durch Ändern des Konfigurationsparameter-Ports in einen anderen verfügbaren Port geändert werden. Beachten Sie, dass Kafka bei der Auswahl eines Ports mit einer Nummer unter 1024 als Root ausgeführt werden sollte. Es wird nicht empfohlen, Kafka als Root auszuführen.

zookeeper.connect

Der Pfad, den ZooKeeper zum Speichern der Metadaten des Brokers verwendet, wird mithilfe des Konfigurationsparameters zookeeper.connect festgelegt. In der Beispielkonfiguration wird ZooKeeper auf Port 2181 auf dem lokalen Host ausgeführt, der als localhost: 2181 angegeben ist. Das Format dieses Parameters ist eine durch Semikolons getrennte Liste von Zeilen des Formulars Hostname: Port / Pfad, einschließlich:

• Hostname - Hostname oder IP-Adresse des ZooKeeper-Servers;
• port - Client-Portnummer für den Server;
• / path - Ein optionaler ZooKeeper-Pfad, der als neuer Root-Pfad (Chroot-Pfad) des Kafka-Clusters verwendet wird. Wenn es nicht angegeben ist, wird der Stammpfad verwendet.

Wenn der angegebene Chroot-Pfad nicht vorhanden ist, wird er beim Start des Brokers erstellt.

log.dirs

Kafka speichert alle Nachrichten auf der Festplatte, und diese Segmente des Protokolls werden in den Verzeichnissen gespeichert, die in der Einstellung log.dirs angegeben sind. Es ist eine durch Kommas getrennte Liste von Pfaden im lokalen System. Wenn mehrere Pfade angegeben sind, speichert der Broker Abschnitte in ihnen nach dem Prinzip der am wenigsten verwendeten, wobei die Protokollsegmente eines Abschnitts entlang eines Pfads erhalten bleiben. Beachten Sie, dass der Broker den neuen Abschnitt in dem Verzeichnis ablegt, in dem derzeit die geringsten Partitionen gespeichert sind und nicht der geringste Speicherplatz verwendet wird, sodass die gleichmäßige Verteilung der Daten auf die Abschnitte nicht gewährleistet ist.

num.recovery.threads.per.data.dir

Kafka verwendet einen benutzerdefinierten Thread-Pool für die Verarbeitung von Protokollsegmenten. Derzeit wird es angewendet:

• während des normalen Starts - um die Protokollsegmente jedes Abschnitts zu öffnen;
• Starten Sie nach einem Fehler, um die Protokollsegmente jedes Abschnitts zu überprüfen und abzuschneiden.
• Stopp - um Protokollsegmente vorsichtig zu schließen.

Standardmäßig wird nur ein Thread pro Protokollverzeichnis verwendet. Da dies nur beim Starten und Stoppen geschieht, ist es sinnvoll, mehr davon zu verwenden, um Operationen zu parallelisieren. Bei der Wiederherstellung nach einem falschen Herunterfahren können die Vorteile dieses Ansatzes mehrere Stunden erreichen, wenn der Broker mit einer großen Anzahl von Partitionen neu gestartet wird! Denken Sie daran, dass der Wert dieses Parameters basierend auf einem Protokollverzeichnis aus der mit log.dirs angegebenen Nummer ermittelt wird. Das heißt, wenn der Wert des Parameters num.recovery.threads.per.data.dir 8 ist und in log.dirs drei Pfade angegeben sind, beträgt die Gesamtzahl der Threads 24.

auto.create.topics.enable

Gemäß der Standardkonfiguration von Kafka sollte der Broker automatisch ein Thema erstellen, wenn:

• Der Hersteller beginnt, in die Betreffzeile zu schreiben.
• Der Verbraucher beginnt, aus dem Thema der Nachricht zu lesen.
• Jeder Client fordert Themen-Metadaten an.

In vielen Fällen kann dieses Verhalten unerwünscht sein, insbesondere aufgrund der Tatsache, dass es nicht möglich ist, die Existenz eines Themas mithilfe des Kafka-Protokolls zu überprüfen, ohne dass es erstellt wird. Wenn Sie die Erstellung explizit, manuell oder über das Initialisierungssystem steuern, können Sie den Parameter auto.create.topics.enable auf false setzen.

Standard-Designeinstellungen

Die Kafka-Serverkonfiguration legt viele Standardeinstellungen für erstellte Themen fest. Einige dieser Parameter, einschließlich der Anzahl der Abschnitte und der Parameter zum Speichern von Nachrichten, können für jedes Thema mithilfe der Administrator-Tools (in Kapitel 9 beschrieben) separat festgelegt werden. Die Standardwerte in der Serverkonfiguration sollten den Referenzwerten entsprechen, die für die meisten Clusterthemen geeignet sind.

Anzahl Partitionen

Der Parameter num.partitions bestimmt, mit wie vielen Abschnitten ein neues Thema erstellt wird, hauptsächlich wenn die automatische Erstellung nach Themen aktiviert ist (dies ist das Standardverhalten). Der Standardwert dieses Parameters ist 1. Beachten Sie, dass die Anzahl der Abschnitte für ein Thema nur erhöht, aber nicht verringert werden kann. Dies bedeutet, dass Sie, wenn weniger Partitionen als in num.partitions angegeben erforderlich sind, diese sorgfältig manuell erstellen müssen (dies wird in Kapitel 9 erläutert).

Wie in Kapitel 1 erläutert, sind Abschnitte eine Möglichkeit, Themen in einem Kafka-Cluster zu skalieren. Daher ist es wichtig, dass Sie über so viele Themen verfügen, wie Sie benötigen, um die Nachrichtenlast im gesamten Cluster auszugleichen, wenn Broker hinzugefügt werden. Viele Benutzer bevorzugen, dass die Anzahl der Partitionen gleich oder die Anzahl der Broker im Cluster ist. Dies ermöglicht eine gleichmäßige Verteilung der Abschnitte unter den Brokern, was zu einer gleichmäßigen Verteilung der Last auf die Nachrichten führt. Dies ist jedoch keine zwingende Voraussetzung, da Sie durch das Vorhandensein mehrerer Themen die Last ausgleichen können.

log.retention.ms

In den meisten Fällen ist die Nachrichtenspeicherung in Kafka zeitlich begrenzt. Der Standardwert wird in der Konfigurationsdatei mit dem Parameter log.retention.hours angegeben und entspricht 168 Stunden oder 1 Woche. Sie können jedoch zwei andere Parameter verwenden - log.retention.minutes und log.retention.ms. Alle drei Parameter bestimmen dasselbe - den Zeitraum, nach dem Nachrichten gelöscht werden. Es wird jedoch empfohlen, den Parameter log.retention.ms zu verwenden, da bei Angabe mehrerer Parameter die Priorität zur kleinsten Maßeinheit gehört, sodass immer der Wert von log.retention.ms verwendet wird.

log.retention.bytes

Eine andere Möglichkeit, die Gültigkeit von Nachrichten einzuschränken, basiert auf der Gesamtgröße (in Byte) der gespeicherten Nachrichten. Der Wert wird mit dem Parameter log.retention.bytes festgelegt und separat angewendet. Dies bedeutet, dass bei einem Thema mit acht Abschnitten und einem Wert von 1 GB des Werts von log.retention.bytes maximal 8 GB Daten für dieses Thema gespeichert werden. Beachten Sie, dass die Speichermenge von den einzelnen Abschnitten und nicht vom Thema abhängt. Dies bedeutet, dass mit zunehmender Anzahl von Abschnitten für das Thema auch die maximale Datenmenge erhöht wird, die bei Verwendung von log.retention.bytes gespeichert wird.

log.segment.bytes

Die genannten Protokollierungseinstellungen betreffen Protokollsegmente und keine einzelnen Nachrichten. Wenn Nachrichten vom Kafka-Broker generiert werden, werden sie am Ende des aktuellen Journalsegments des entsprechenden Abschnitts hinzugefügt. Wenn das Protokollsegment die im Parameter log.segment.bytes angegebene Größe erreicht und standardmäßig 1 GB entspricht, wird dieses Segment geschlossen und ein neues geöffnet. Nach dem Schließen kann das Journalsegment eingestellt werden. Je kleiner die Protokollsegmente sind, desto häufiger müssen Sie Dateien schließen und neue erstellen, was die Gesamteffizienz von Festplattenschreibvorgängen verringert.

Die Größe von Protokollsegmenten ist wichtig, wenn Themen durch eine geringe Häufigkeit der Nachrichtengenerierung gekennzeichnet sind. Wenn ein Thema beispielsweise nur 100 MB Nachrichten pro Tag empfängt und der Parameter log.segment.bytes auf den Standardwert gesetzt ist, dauert das Ausfüllen eines Segments 10 Tage. Und da Nachrichten erst nach dem Schließen des Protokollsegments für ungültig erklärt werden können, können sich Nachrichten mit dem Wert 604,8 Millionen (1 Woche) des Parameters log.retention.ms innerhalb von 17 Tagen ansammeln, bevor das geschlossene Protokollsegment aus dem Verkehr gezogen wird. Dies liegt daran, dass Sie beim Schließen eines Segments mit Nachrichten, die sich über 10 Tage angesammelt haben, diese weitere 7 Tage speichern müssen, bevor Sie sie gemäß den festgelegten temporären Regeln zurückziehen können, da das Segment nicht gelöscht werden kann, bevor die letzte darin enthaltene Nachricht abläuft .

log.segment.ms

Eine andere Möglichkeit, das Schließen von Protokollsegmenten zu steuern, ist die Verwendung des Parameters log.segment.ms, der die Zeitdauer angibt, nach der das Protokollsegment geschlossen wird. Wie die Parameter log.retention.bytes und log.retention.ms schließen sich die Parameter log.segment.bytes und log.segment.ms nicht gegenseitig aus. Kafka schließt das Protokollsegment, wenn entweder die Zeit abgelaufen ist oder die angegebene Größenbeschränkung erreicht ist, je nachdem, welches dieser Ereignisse zuerst auftritt. Standardmäßig ist der Wert des Parameters log.segment.ms nicht festgelegt, wodurch das Schließen der Protokollsegmente durch ihre Größe bestimmt wird.

message.max.bytes

Der Kafka-Broker ermöglicht die Verwendung des Parameters message.max.bytes, um die maximale Größe der generierten Nachrichten zu begrenzen. Der Standardwert für diesen Parameter ist 1.000.000 (1 MB). Ein Hersteller, der versucht, eine größere Nachricht zu senden, erhält eine Fehlerbenachrichtigung vom Broker, die jedoch nicht akzeptiert wird. Wie bei allen anderen Größen in Bytes, die in den Einstellungen des Brokers angegeben sind, handelt es sich um die Größe der komprimierten Nachricht, sodass Hersteller Nachrichten senden können, deren unkomprimierte Größe viel größer ist, wenn sie auf die in message.max.bytes angegebenen Grenzen komprimiert werden können .

Das Erhöhen der Größe der Nachricht kann die Leistung erheblich beeinträchtigen. Eine größere Nachrichtengröße bedeutet, dass Broker-Threads, die Netzwerkverbindungen und -anforderungen verarbeiten, für jede Anforderung länger dauern. Größere Nachrichten erhöhen auch die auf die Festplatte geschriebene Datenmenge, was sich auf den E / A-Durchsatz auswirkt.

Hardwareauswahl

Die Wahl der richtigen Hardware für den Kafka-Broker ist eher eine Kunst als eine Wissenschaft. Die Kafka-Plattform selbst hat keine strengen Hardwareanforderungen und funktioniert auf jedem System problemlos. Wenn wir jedoch über die Leistung sprechen, wird dies von mehreren Faktoren beeinflusst: Kapazität und Durchsatz von Festplatten, RAM, Netzwerk und CPU.

Zuerst müssen Sie entscheiden, welche Leistungstypen für Ihr System am wichtigsten sind. Anschließend können Sie die optimale Hardwarekonfiguration auswählen, die in das Budget passt.

Festplattendurchsatz

Der Durchsatz von Broker-Festplatten, die zum Speichern von Protokollsegmenten verwendet werden, wirkt sich direkt auf die Leistung der Fertigungskunden aus. Kafka-Nachrichten müssen in den lokalen Speicher übertragen werden, der ihre Aufzeichnung bestätigt. Nur dann kann der Sendevorgang als erfolgreich angesehen werden. Dies bedeutet, dass die Verzögerung bei der Nachrichtengenerierung umso geringer ist, je schneller die Schreibvorgänge auf die Festplatte ausgeführt werden.

Die offensichtliche Maßnahme bei Problemen mit der Bandbreite von Festplatten ist die Verwendung von Festplatten mit rotierenden Platten (HDD) oder Solid-State-Laufwerken (SSD). SSDs haben um Größenordnungen geringere Such- / Zugriffszeiten und eine höhere Leistung. Festplatten sind wirtschaftlicher und haben eine höhere relative Kapazität. Die Festplattenleistung kann aufgrund der größeren Anzahl im Broker oder durch Verwendung mehrerer Datenverzeichnisse oder durch Installation von Festplatten in einem Array unabhängiger Festplatten mit Redundanz (redundantes Array unabhängiger Festplatten, RAID) verbessert werden. Andere Faktoren beeinflussen den Durchsatz, beispielsweise die Technologie zur Herstellung einer Festplatte (z. B. SAS oder SATA) sowie die Eigenschaften des Festplattencontrollers.

Festplattenkapazität

Kapazität ist ein weiterer Aspekt der Speicherung. Der erforderliche Speicherplatz hängt davon ab, wie viele Nachrichten gleichzeitig gespeichert werden müssen. Wenn erwartet wird, dass der Broker 1 TB Datenverkehr pro Tag empfängt, benötigt er bei einem 7-Tage-Speicher verfügbaren Speicher für Protokollsegmente mit mindestens 7 TB. Sie sollten auch einen Überlauf von mindestens 10% für andere Dateien in Betracht ziehen, ohne den Puffer für mögliche Verkehrsschwankungen oder dessen Wachstum im Laufe der Zeit zu berücksichtigen.

Die Speicherkapazität ist einer der Faktoren, die bei der Bestimmung der optimalen Kafka-Clustergröße und der Entscheidung über deren Erweiterung berücksichtigt werden müssen. Der gesamte Clusterverkehr kann durch mehrere Abschnitte für jedes Thema ausgeglichen werden, sodass Sie zusätzliche Broker verwenden können, um die verfügbare Kapazität zu erhöhen, wenn die Datendichte pro Broker nicht ausreicht. Die Entscheidung darüber, wie viel Speicherplatz benötigt wird, hängt auch von der für den Cluster ausgewählten Replikationsstrategie ab (ausführlicher in Kapitel 6 erläutert).

Die Erinnerung

Im normalen Betriebsmodus liest der Verbraucher Kafka am Ende des Abschnitts, und der Verbraucher gleicht die verlorene Zeit ständig aus und liegt, wenn überhaupt, nur geringfügig hinter den Herstellern. , , . , , -.

Kafka JVM . , X X , 5 . Kafka . Kafka , , , Kafka.

, Kafka, . ( ) . Kafka ( ) . 1 , , . , (. 6) ( 8). , .

CPU

, , . . Kafka, , . . Kafka ' . .

Kafka

Kafka , , Amazon Web Services (AWS). AWS , CPU, . Kafka. , . / SSD. (, AWS Elastic Block Store). CPU .
, AWS m4 r3. m4 , , . r3 SSD-, . i2 d2.

Kafka

Kafka , (. 2.2). — . — . Kafka . Kafka. 6.

?

Kafka . — . 10 , 2 , — . , 100 % ( ) (. 6). , .

, , — . , ( ). 80 % , , . , , . , , .

Kafka. — zookeeper.connect. ZooKeeper . — broker.id. broker.id , . , , , .

Linux , , Kafka. , , . /etc/sysctl.conf, Linux, .

Linux . , «» , Kafka.
, , , () . , , Kafka. , Kafka , , .

— . — , - . . vm.swappiness , 1. ( ) , . , .

, «» , , . Kafka /. : (, SSD), NVRAM (, RAID). «» , . vm.dirty_background_ratio , ( 10). ( ), 5. 0, .

«» , , vm.dirty_ratio , — 20 ( ). , 60 80. , / . vm.dirty_ratio Kafka, .

«» Kafka . /proc/vmstat:

 # cat /proc/vmstat | egrep "dirty|writeback" nr_dirty 3875 nr_writeback 29 nr_writeback_temp 0 # 

Fahren

, RAID- , . , EXT4 (fourth extended file system — ) XFS (Extents File System — ). EXT4 , . , (5), . EXT4 , . XFS , , EXT4. XFS Kafka , , . , /.

, , noatime. /: (ctime), (mtime) (atime). atime . . atime , , , ( realtime). Kafka atime, . noatime /, ctime mtime.

Linux — , , . Kafka , - . ( ) , . . net.core.wmem_default net.core.rmem_default , 2 097 152 (2 ). , , .

TCP net.ipv4.tcp_wmem net.ipv4.tcp_rmem. , , . — 4096 65536 2048000 — , 4 , — 64 , — 2 . , net.core.wmem_max net.core.rmem_max. Kafka .

. TCP 1 net.ipv4.tcp_window_scaling, . net.ipv4.tcp_max_syn_backlog , 1024, . net.core.netdev_max_backlog, 1000, , , , .

Kafka , .

Java , , . , Java 7 Garbage First (G1). G1 . , , .

G1 . .

• MaxGCPauseMillis. . — G1 . 200 . , G1 , , , , 200 .
• InitiatingHeapOccupancyPercent. , . 45. , G1 , 45 % , (Eden), .

Kafka , . 64 , Kafka 5 . 20 MaxGCPauseMillis. InitiatingHeapOccupancyPercent 35, , .

Kafka G1, . . :

 # export JAVA_HOME=/usr/java/jdk1.8.0_51 # export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true" # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

Kafka , . - , . Kafka (. 6), . Kafka, .

Kafka , , ( , , AWS), , . . , «» (. 6).

: Kafka , , , . ( ) . , , .

ZooKeeper

Kafka ZooKeeper , . ZooKeeper Kafka. , ZooKeeper Kafka . ZooKeeper Kafka ( ZooKeeper , ).

ZooKeeper . ZooKeeper, Kafka, . ZooKeeper , ZooKeeper . — 1 , . ZooKeeper, , . ZooKeeper , . , Kafka Kafka ZooKeeper.

Kafka, , . Kafka ZooKeeper, . ZooKeeper, . , , , . , , .

Zusammenfassung

, Apache Kafka. , , . , Kafka, Kafka. Kafka ( 3), ( 4).

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers
» Inhalt
» Auszug

20% — Apache Kafka