Rekommenderade konfigurationer för Apache Kafka-klienter
Här är de rekommenderade konfigurationerna för att använda Azure Event Hubs från Apache Kafka-klientprogram.
Egenskaper för Java-klientkonfiguration
Producent- och konsumentkonfigurationer
| Property | Rekommenderade värden | Tillåtet intervall | Kommentar |
|---|---|---|---|
metadata.max.age.ms |
180000 (ungefärlig) | < 240000 | Kan sänkas för att hämta metadataändringar tidigare. |
connections.max.idle.ms |
180000 | < 240000 | Azure stänger inkommande TCP-inaktiva > 240 000 ms, vilket kan resultera i att döda anslutningar skickas (visas som utgångna batchar på grund av tidsgränsen för sändning). |
Endast producentkonfigurationer
Producentkonfigurationer finns här.
| Property | Rekommenderade värden | Tillåtet intervall | Kommentar |
|---|---|---|---|
max.request.size |
1 000 000 | < 1046528 | Tjänsten stänger anslutningar om begäranden som är större än 1 046 528 byte skickas. Det här värdet måste ändras och orsakar problem i scenarier med högt dataflöde. |
retries |
> 0 | Du kan behöva öka delivery.timeout.ms värde i dokumentationen. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Event Hubs kommer internt att vara minst 20 000 ms. Även om begäranden med lägre tidsgränsvärden accepteras garanteras inte klientbeteendet.. Kontrollera att din request.timeout.ms är minst det rekommenderade värdet 60000 och att din session.timeout.ms är minst det rekommenderade värdet 30000. Om de här inställningarna är för låga kan det orsaka tidsgränser för konsumenterna, vilket sedan orsakar ombalanseringar (vilket sedan orsakar fler timeouter, vilket orsakar mer ombalansering och så vidare). |
metadata.max.idle.ms |
180000 | > 5000 | Styr hur länge producenten cachelagrade metadata för ett ämne som är inaktivt. Om den förflutna tiden sedan ett ämne senast producerades överskrider varaktigheten för inaktiva metadata glöms ämnets metadata bort och nästa åtkomst till det framtvingar en begäran om metadatahämtning. |
linger.ms |
> 0 | För scenarier med högt dataflöde bör värdet vara lika med det högsta toleransvärdet för att dra nytta av batchbearbetning. | |
delivery.timeout.ms |
Ange enligt formeln (request.timeout.ms + linger.ms) * . retries |
||
compression.type |
none |
Komprimering stöds för närvarande inte.. |
Endast konsumentkonfigurationer
Konsumentkonfigurationer finns här.
| Property | Rekommenderade värden | Tillåtet intervall | Kommentar |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 är standardvärdet och bör inte ändras. | |
session.timeout.ms |
30000 | 6000 .. 300 000 | Börja med 30000, öka om du ser frekvent ombalansering på grund av missade pulsslag. Kontrollera att din request.timeout.ms är minst det rekommenderade värdet 60000 och att din session.timeout.ms är minst det rekommenderade värdet 30000. Om de här inställningarna är för låga kan det orsaka tidsgränser för konsumenterna, vilket sedan orsakar ombalanseringar (vilket sedan orsakar fler timeouter, vilket orsakar mer ombalansering och så vidare). |
max.poll.interval.ms |
300000 (standard) | >session.timeout.ms | Används för ombalanseringstimeout, så detta bör inte anges för lågt. Måste vara större än session.timeout.ms. |
librdkafka-konfigurationsegenskaper
librdkafka Huvudkonfigurationsfilen (länk) innehåller utökade beskrivningar för egenskaperna nedan.
Producent- och konsumentkonfigurationer
| Property | Rekommenderade värden | Tillåtet intervall | Kommentar |
|---|---|---|---|
socket.keepalive.enable |
true | Nödvändigt om anslutningen förväntas vara inaktiv. Azure stänger inkommande TCP-inaktiva > 240 000 ms. | |
metadata.max.age.ms |
~ 180000 | < 240000 | Kan sänkas för att hämta metadataändringar tidigare. |
Endast producentkonfigurationer
| Property | Rekommenderade värden | Tillåtet intervall | Kommentar |
|---|---|---|---|
retries |
> 0 | Standardvärdet är 2147483647. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Event Hubs kommer internt att vara minst 20 000 ms. librdkafka standardvärdet är 5 000, vilket kan vara problematiskt. Även om begäranden med lägre tidsgränsvärden accepteras garanteras inte klientbeteendet. |
partitioner |
consistent_random |
Se dokumentationen om librdkafka | consistent_random är standard och bäst. Tomma och null-nycklar hanteras helst i de flesta fall. |
compression.codec |
none |
Komprimering stöds för närvarande inte. |
Endast konsumentkonfigurationer
| Property | Rekommenderade värden | Tillåtet intervall | Kommentar |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 är standardvärdet och bör inte ändras. | |
session.timeout.ms |
30000 | 6000 .. 300 000 | Börja med 30000, öka om du ser frekvent ombalansering på grund av missade pulsslag. |
max.poll.interval.ms |
300000 (standard) | >session.timeout.ms | Används för ombalanseringstimeout, så detta bör inte anges för lågt. Måste vara större än session.timeout.ms. |
Ytterligare kommentarer
Kontrollera följande tabell med vanliga konfigurationsrelaterade felscenarier.
| Symtom | Problem | Lösning |
|---|---|---|
| Förskjutning av incheckningsfel på grund av ombalansering | Din konsument väntar för länge mellan anrop till poll() och tjänsten sparkar ut konsumenten ur gruppen. | Du har flera alternativ:
|
| Nätverksfel vid hög produktion av dataflöde | Använder du Java-klienten + standardvärdet max.request.size? Dina begäranden kan vara för stora. | Se Java-konfigurationer ovan. |
Nästa steg
Se Azure-prenumerations - och tjänstgränser, kvoter och begränsningar för kvoter och gränser för alla Azure-tjänster.