Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 den eingehenden Transmission Control Protocol (TCP) im Leerlauf > um 240.000 ms, was dazu führen kann, dass tote Verbindungen gesendet werden (als abgelaufene Batches aufgrund von Send-Timeout 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, die größer als 1.046.528 Byte sind, gesendet werden. Dieser Wert muss geändert werden und verursacht Probleme in Szenarien mit hohem Durchsatz. |
retries |
> 0 | Es könnte eine Wertsteigerung delivery.timeout.ms erfordern, siehe Dokumentation. |
|
request.timeout.ms |
30.000 60000 | > 20.000 | Event Hubs werden intern auf mindestens 20.000 ms festgelegt. Produzenten-Timeouts sind mit Werten bis zu 10.000 ms sicher und werden für Produzenten kein Problem darstellen. 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 das zu Consumer-Timeouts führen, die wiederum zu Rebalances führen (was wiederum zu weiteren Time-Outs führt, was wiederum mehr Rebalancing und so weiter verursacht). |
metadata.max.idle.ms |
180.000 | > 5.000 | Steuert, wie lange der Produzent Metadaten für ein Thema zwischenspeichert, das im Leerlauf ist. 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, gzip |
Zurzeit wird nur gzip-Komprimierung 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 das zu Consumer-Timeouts führen, die wiederum zu Rebalances führen (was wiederum zu weiteren Time-Outs führt, was wiederum mehr Rebalancing und so weiter verursacht). |
max.poll.interval.ms |
300.000 (Standard) | >session.timeout.ms | Wird für das Rebalance-Timeout verwendet, daher sollte es nicht zu niedrig eingestellt sein. Der Wert muss größer als der Wert für „session.timeout.ms“ sein. |
librdkafka-Konfigurationseigenschaften
Die Hauptkonfigurationsdatei librdkafka (Link) enthält erweiterte Beschreibungen für die in den folgenden Abschnitten beschriebenen 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-Leerlauf > 240.000 ms. | |
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 | Notizen |
|---|---|---|---|
retries |
> 0 | Der Standardwert ist 2147483647. | |
request.timeout.ms |
30.000 60000 | > 20.000 | Event Hubs werden intern auf mindestens 20.000 ms festgelegt. Der librdkafka-Standardwert ist 5.000. Dies kann problematisch sein.
Während Anfragen mit niedrigeren Timeout-Werten akzeptiert werden, ist das Verhalten der Klienten 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, gzip |
Zurzeit wird nur gzip-Komprimierung 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 die Rebalance-Zeit verwendet, daher sollte es nicht zu niedrig eingestellt werden. 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:
|
| Netzwerkausnahmen bei hohem Producerdurchsatz | Wenn Sie java client + default max.request.size verwenden, sind Ihre Anforderungen möglicherweise zu groß. | Siehe zuvor erwähnte 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.