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 | Notizen |
|---|---|---|---|
retries |
2 | 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 Möglichkeiten:
|
| 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.