Freigeben über


Empfohlene Konfigurationen für Apache Kafka-Clients

Hier finden Sie die empfohlenen Konfigurationen für die Verwendung von Azure Event Hubs aus Apache Kafka-Clientanwendungen.

Java-Clientkonfigurationseigenschaften

Producer- und Consumerkonfigurationen

Eigenschaft Empfohlene Werte Zulässiger Bereich Notizen
metadata.max.age.ms 180.000 (ungefähr) < 240.000 Kann verringert werden, um Metadatenänderungen früher zu übernehmen.
connections.max.idle.ms 180.000 < 240.000 Azure schließt eingehende TCP-Verbindungen, die sich länger als 240.000 ms im Leerlauf befinden, was zum Senden über stillgelegte Verbindungen führen kann. Dies wird aufgrund des Sendetimeouts als abgelaufene Batches angezeigt.

Nur Producerkonfigurationen

Producerkonfigurationen finden Sie hier.

Eigenschaft Empfohlene Werte Zulässiger Bereich Notizen
max.request.size 1000000 < 1.046.528 Der Dienst schließt Verbindungen, wenn Anforderungen gesendet werden, die größer als 1.046.528 Bytes sind. Dieser Wert muss geändert werden und führt zu Problemen bei Szenarien mit hohem Durchsatz.
retries > 0 Erfordert möglicherweise eine Erhöhung des delivery.timeout.ms-Werts. Weitere Informationen finden Sie in der Dokumentation.
request.timeout.ms 30.000 60000 > 20.000 Event Hubs wird intern standardmäßig auf mindestens 20.000 ms festgelegt. Obwohl Anforderungen mit niedrigeren Timeoutwerten akzeptiert werden, wird das Clientverhalten nicht garantiert.

Stellen Sie sicher, dass Ihr Wert für request.timeout.ms mindestens dem empfohlenen Wert 60000 und Ihr Wert für session.timeout.ms mindestens dem empfohlenen Wert 30000 entspricht. Wenn diese Einstellungen zu niedrig sind, kann dies zu Zeitüberschreitungen von Consumern führen, die dann zu Ausgleichvorgängen führen (was dann zu mehr Zeitüberschreitungen führt, was wiederum zu mehr Ausgleichvorgängen führt usw.).

metadata.max.idle.ms 180.000 > 5.000 Steuert, wie lange der Producer Metadaten für ein Thema zwischenspeichert, das sich im Leerlauf befindet. Wenn die Zeit, die seit der letzten Erstellung eines Themas verstrichen ist, die Leerlaufzeit der Metadaten überschreitet, werden die Metadaten des Themas verworfen, und der nächste Zugriff darauf erzwingt eine Anforderung zum Abrufen der Metadaten.
linger.ms > 0 Bei Szenarien mit hohem Durchsatz sollte der Verweilwert gleich dem höchsten tolerablen Wert sein, um Batchverarbeitung zu nutzen.
delivery.timeout.ms Wird gemäß der Formel (request.timeout.ms + linger.ms) * retries festgelegt.
compression.type none Komprimierung wird derzeit nicht unterstützt.

Nur Consumerkonfigurationen

Consumerkonfigurationen finden Sie hier.

Eigenschaft Empfohlene Werte Zulässiger Bereich Notizen
heartbeat.interval.ms 3000 3\.000 ist der Standardwert und sollte nicht geändert werden.
session.timeout.ms 30.000 6\.000 300000 Beginnen Sie mit 30.000, und vergrößern Sie den Wert bei einem häufigen Ausgleich aufgrund von verpassten Takten.

Stellen Sie sicher, dass Ihr Wert für request.timeout.ms mindestens dem empfohlenen Wert 60000 und Ihr Wert für session.timeout.ms mindestens dem empfohlenen Wert 30000 entspricht. Wenn diese Einstellungen zu niedrig sind, kann dies zu Zeitüberschreitungen von Consumern führen, die dann zu Ausgleichvorgängen führen (was dann zu mehr Zeitüberschreitungen führt, was wiederum zu mehr Ausgleichvorgängen führt usw.).

max.poll.interval.ms 300.000 (Standard) >session.timeout.ms Wird für das Ausgleichstimeout verwendet, daher sollte der Wert nicht zu niedrig sein. Der Wert muss größer als der Wert für „session.timeout.ms“ sein.

librdkafka-Konfigurationseigenschaften

Die librdkafka-Hauptkonfigurationsdatei (Link) enthält erweiterte Beschreibungen für die unten aufgeführten Eigenschaften.

Producer- und Consumerkonfigurationen

Eigenschaft Empfohlene Werte Zulässiger Bereich Notizen
socket.keepalive.enable true Erforderlich, wenn erwartet wird, dass die Verbindung im Leerlauf ist. Azure schließt eingehende TCP-Verbindungen,die länger als 240.000 ms im Leerlauf sind.
metadata.max.age.ms ~ 180.000 < 240.000 Kann verringert werden, um Metadatenänderungen früher zu übernehmen.

Nur Producerkonfigurationen

Eigenschaft Empfohlene Werte Zulässiger Bereich Hinweise
retries > 0 Der Standardwert ist 2147483647.
request.timeout.ms 30.000 60000 > 20.000 Event Hubs wird intern standardmäßig auf mindestens 20.000 ms festgelegt. Der librdkafka-Standardwert ist 5.000. Dies kann problematisch sein. Obwohl Anforderungen mit niedrigeren Timeoutwerten akzeptiert werden, wird das Clientverhalten nicht garantiert.
partitioner consistent_random Weitere Informationen finden Sie in der librdkafka-Dokumentation. consistent_random ist Standard und am besten geeignet. Leere und NULL-Schlüssel werden in den meisten Fällen ideal behandelt.
compression.codec none Komprimierung wird derzeit nicht unterstützt.

Nur Consumerkonfigurationen

Eigenschaft Empfohlene Werte Zulässiger Bereich Notizen
heartbeat.interval.ms 3000 3\.000 ist der Standardwert und sollte nicht geändert werden.
session.timeout.ms 30.000 6\.000 300000 Beginnen Sie mit 30.000, und vergrößern Sie den Wert bei einem häufigen Ausgleich aufgrund von verpassten Takten.
max.poll.interval.ms 300.000 (Standard) >session.timeout.ms Wird für das Ausgleichstimeout verwendet, daher sollte der Wert nicht zu niedrig sein. Der Wert muss größer als der Wert für „session.timeout.ms“ sein.

Weitere Hinweise

Überprüfen Sie die folgende Tabelle mit allgemeinen konfigurationsbezogenen Fehlerszenarien.

Symptome Problem Lösung
Offsetcommitfehler aufgrund eines erneuten Ausgleichs Der Consumer wartet zu lange zwischen Aufrufen von poll(), und der Dienst entfernt den Consumer aus der Gruppe. Sie haben mehrere Optionen:
  • Erhöhen des Timeouts für die Abrufverarbeitung (max.poll.interval.ms)
  • Verkleinern der Nachrichtenbatchgröße, um die Verarbeitung zu beschleunigen
  • Verbessern der Verarbeitungsparallelisierung, um das Blockieren von consumer.poll() zu vermeiden
Das Anwenden einer Kombination dieser drei Optionen ist wahrscheinlich am sinnvollsten.
Netzwerkausnahmen bei hohem Producerdurchsatz Verwenden Sie einen Java-Client und den Standardwert von max.request.size? Ihre Anforderungen sind möglicherweise zu groß. Weitere Informationen finden Sie oben unter den Java-Konfigurationen.

Nächste Schritte

Informationen zu Kontingenten und Einschränkungen finden Sie unter Einschränkungen für Azure-Abonnements und -Dienste, Kontingente und Einschränkungen.