Apache Kafka verwenden

Broker optimieren

Sie steuern die Anzahl der Partitionen in einem Thema. Die Erhöhung der Anzahl der Partitionen und der Anzahl der Broker in einem Cluster führt zu einer erhöhten Parallelität des Nachrichtenverbrauchs, was wiederum den Durchsatz eines Kafka-Clusters verbessert. Die für die Replikation von Daten über Replikatsets erforderliche Zeit nimmt jedoch ebenfalls zu.

Producer optimieren

Sie können einen Producer in zwei verschiedenen Modi ausführen: synchron und asynchron. Im synchronen Modus sendet der Producer, sobald eine Nachricht veröffentlicht wird, eine Anforderung an den Broker. Wenn Sie also 100 Nachrichten pro Sekunde erstellen, sendet der Producer 100 Anforderungen eine Sekunde an den Broker. Dies verringert den Durchsatz und wirkt als Sperrvorgang. Wenn Sie also eine hohe Anzahl von Nachrichten veröffentlichen, ist es besser, Producer im asynchronen Modus auszuführen.

Im asynchronen Modus müssen Sie zwei Parameter optimieren, um die beste Performance zu erzielen: batch.size und linger.ms (Lingerzeit). Die Batchgröße ist die Größe der Daten, die in einem Batch gesendet werden sollen, gemessen in Byte. Beispiel: Wenn Sie die Batchgröße auf 100 setzen, wartet der Producer, bis die Nachrichten 100 Byte ergeben, bevor er den Broker anruft. Wenn die Nachrichtenproduktion niedrig ist und Sie eine hohe Batchgröße festlegen, wartet der Producer lange, bevor er schließlich Nachrichten erstellt. Dadurch wird der Durchsatz reduziert und die Latenz bei der Nachrichtenzustellung erhöht. Daher muss dieser Wert je nach Anzahl der erzeugten Nachrichten optimiert werden. Die Standardbatchgröße ist 16.384.

Die Verweildauer ist eine weitere Metrik, die darauf basiert, wann ein Produzent beschließt, eine Anforderung an einen Broker zu senden. Wenn die Batchgröße im vorherigen Beispiel auf 100 Byte gesetzt ist und Sie nur 50 Byte pro Sekunde produzieren, muss der Producer zwei Sekunden warten, bevor diese Nachrichten veröffentlicht werden. Um diese Verzögerung zu vermeiden, können Sie die Verweildauer (gemessen in Millisekunden) optimieren, um sicherzustellen, dass der Producer nicht zu lange wartet, bevor er Nachrichten sendet. Wenn die Verweildauer in diesem Beispiel auf 500 ms gesetzt wird, wartet der Produzent höchstens eine halbe Sekunde.

Komprimierung kann auch die Latenz verbessern. Standardmäßig werden Kafka-Nachrichten nicht komprimiert. Sie können jedoch Producer konfigurieren, um sie zu komprimieren. Broker und Consumer haben dann den zusätzlichen Overhead beim Dekomprimieren von Nachrichten, aber die Gesamtlatenz sollte reduziert werden, da die physische Größe der über das Netzwerk übertragenen Daten kleiner ist.

Consumer optimieren

Verbraucher erhalten Nachrichten in Batches, ähnlich wie Producer in Batches veröffentlichen. Wenn Sie viele Nachrichten abrufen und viel Zeit in Anspruch nehmen, um jede einzelne zu verarbeiten, leidet der Durchsatz. Wenn Sie den Broker jedes Mal nach einer einzelnen Nachricht fragen, kann die Anzahl der Anforderungen an den Broker den Durchsatz verringern.

Wenn mehr Partitionen und Consumer in einer Consumer-Gruppe vorhanden sind, kann der Durchsatz verbessert werden. Denken Sie jedoch daran, dass mit zunehmender Anzahl von Verbrauchern auch die Anzahl der Offset-Commit-Anforderungen an den Broker steigt. Da beim Festschreiben eines Offsets eine Kafka-Nachricht an ein internes Thema gesendet wird, erhöht sich dadurch die Belastung des Brokers indirekt. Daher ist es entscheidend, eine optimale Anzahl von Verbrauchern zu haben.

MirrorMaker Performanceoptimierung

Kafka MirrorMaker ist ein Tool zum Spiegeln von Kafka-Nachrichten von einem Data Center oder Cluster in ein anderes. Da dies intern Nachrichten an Kafka erzeugt, gelten auch hier die meisten bereits diskutierten Optimierungstechniken. Da dies auch die Übertragung von Nachrichten über große Entfernungen umfasst, gibt es einige weitere Konfigurationsparameter, die für eine bessere Performance optimiert werden können.

• MirrorMaker2 Speicherort: MirrorMaker kann entweder an der Quelle oder am Ziel installiert werden. Wir empfehlen jedoch, am Ziel zu installieren, da das Erstellen von Nachrichten über große Entfernungen die Wahrscheinlichkeit erhöht, dass Daten während der Übertragung verloren gehen.
• Komprimierung: Standardmäßig ist die Nachrichtenkomprimierung in Kafka-Producern auf "Keine" gesetzt. Um jedoch Nachrichten zu komprimieren, die von der Quelle zum Ziel ausgehen, ändern Sie die Komprimierung in gzip. Dies hilft bei größeren Losgrößen.
• Batchgröße: Wenn die Batchgröße von Nachrichten erhöht wird, erhöht sich der Durchsatz. Durch die Kombination mit Komprimierung wird sichergestellt, dass eine große Anzahl von Nachrichten schnell übertragen werden. Wenn die Zielbatchgröße mehr Zeit in Anspruch nimmt als die konfigurierte Verweilzeit, werden die ausgehenden Batches nicht vollständig gefüllt. Dies verringert die Komprimierungseffizienz und verschwendet die Bandbreite. Daher ist es wichtig, die Batchgröße zusammen mit der Aktivierung der Komprimierungs- und Optimierungsdauer zu optimieren.
• Verweilzeit: Es ist wichtig, die Verweilzeit zu erhöhen, damit Chargen vollständig gefüllt werden können. Dies kann die Latenz erhöhen, aber der Gesamtdurchsatz verbessert sich. Sie müssen überlegen, wie wichtig Latenz für Ihren Geschäftsanwendungsfall ist.
• Parallelität erhöhen: Um den Durchsatz weiter zu erhöhen, können Sie mehrere Instanzen von MirrorMaker unter derselben Nutzungsgruppe bereitstellen. Dies erleichtert mehrere MirrorMaker-Consumer, die von derselben Quelle empfangen und parallel zum Ziel produzieren.

Produktionsserverkonfigurationen im Kafka-Tuning

Mehrere andere Konfigurationsparameter können optimiert werden, um die Performance von Kafka in einer Produktionsumgebung zu verbessern. Die folgenden Parameter verbessern die Replikationsperformance von Nachrichten innerhalb von Partitionen:

• num.replica.fetchers: Gibt die Anzahl der Threads an, die zum Replizieren von Nachrichten vom Leader auf die Follower verwendet werden. Eine größere Anzahl von Replikat-Fetchern verbessert die Parallelität bei der Replikation.
• replica.fetch.max.bytes: Gibt die Anzahl der Byte an Daten an, die vom Leader abgerufen werden sollen. Eine größere Anzahl weist auf einen größeren Datenblock hin, der abgerufen wird, was den Durchsatz der Replikation verbessert.
• num.partitions: Gibt die maximale Anzahl von Consumern an, die ein Thema in einer bestimmten Benutzergruppe haben kann. Dies entspricht der Anzahl der Partitionen, die in diesem Thema verfügbar sind. Die Erhöhung der Partitionen erhöht die Parallelität und damit den Durchsatz. Viele Partitionen verbrauchen jedoch auch mehr Ressourcen. Daher müssen Sie auch Ressourcen vertikal skalieren.

Apache Kafka-Cluster ausgleichen

Wenn einem Kafka-Cluster ein neuer Broker hinzugefügt wird, werden vorhandene Partitionen nicht über den neuen Broker verteilt. Dies bedeutet, dass der neue Broker nicht beschäftigt ist, und wenn ein oder mehrere alte Broker ausfallen, werden Replikation und potenzielle Führungskräfte reduziert. Das nennt man Leader Skew. Sie können dies vermeiden, indem Sie sicherstellen, dass jeder neu hinzugefügte Broker einen Teil der Partitionen erhält. Ein Rebalancing des Clusters ist wichtig. Wenn ein Broker über mehr als die durchschnittliche Anzahl von Partitionen für ein Thema verfügt, das als Broker-Skew bezeichnet wird, kann dies zu Performanceproblemen führen.

Kafka-Performance optimieren

Bei der Ausführung von Kafka als Cluster gibt es mehrere Möglichkeiten, die Performance zu optimieren. Sie können verschiedene Konfigurationsparameter optimieren, um ein Gleichgewicht zwischen Durchsatz und Latenz herzustellen. Engineering ist daran beteiligt, die besten Werte für einige dieser Parameter zu berechnen, wie Verweilzeit, Batchgröße, Anzahl der Partitionen usw. Je nach Anwendungsfall können Sie entscheiden, dass der Durchsatz wichtiger ist als die Latenz, dass die Latenz wichtiger ist als der Durchsatz oder dass ein Gleichgewicht zwischen beiden am besten ist.