Zalecane konfiguracje dla klientów platformy Apache Kafka
Poniżej przedstawiono zalecane konfiguracje korzystania z usługi Azure Event Hubs z aplikacji klienckich platformy Apache Kafka.
Właściwości konfiguracji klienta Java
Konfiguracje producentów i konsumentów
| Właściwości | Zalecane wartości | Dozwolony zakres | Uwagi |
|---|---|---|---|
metadata.max.age.ms |
180000 (przybliżona) | < 240000 | Można obniżyć, aby szybciej pobierać zmiany metadanych. |
connections.max.idle.ms |
180000 | < 240000 | Platforma Azure zamyka przychodzące bezczynność > protokołu TCP 240 000 ms, co może spowodować wysłanie na nieaktywne połączenia (pokazane jako wygasłe partie z powodu przekroczenia limitu czasu wysyłania). |
Tylko konfiguracje producenta
Konfiguracje producenta można znaleźć tutaj.
| Właściwości | Zalecane wartości | Dozwolony zakres | Uwagi |
|---|---|---|---|
max.request.size |
1000000 | < 1046528 | Usługa zamknie połączenia, jeśli wysyłane są żądania większe niż 1046 528 bajtów. Ta wartość musi zostać zmieniona i spowoduje problemy w scenariuszach tworzenia o wysokiej przepływności. |
retries |
> 0 | Może wymagać zwiększenia delivery.timeout.ms wartości, zobacz dokumentację. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Usługa Event Hubs będzie domyślnie domyślna co najmniej 20 000 ms. Chociaż żądania z niższymi wartościami limitu czasu są akceptowane, zachowanie klienta nie jest gwarantowane. Upewnij się, że request.timeout.ms jest co najmniej zalecaną wartością 60000, a session.timeout.ms jest co najmniej zalecaną wartością 30000. Jeśli te ustawienia są zbyt niskie, mogą spowodować przekroczenia limitu czasu użytkownika, co spowoduje ponowne równoważenie (co powoduje większe przekroczenie limitu czasu, co powoduje ponowne równoważenie itd.). |
metadata.max.idle.ms |
180000 | > 5000 | Określa, jak długo producent buforuje metadane tematu, który jest bezczynny. Jeśli czas, który upłynął od czasu ostatniego utworzenia tematu, przekracza czas bezczynności metadanych, metadane tematu zostaną zapomniane, a następny dostęp do niego wymusi żądanie pobierania metadanych. |
linger.ms |
> 0 | W przypadku scenariuszy o wysokiej przepływności wartość utrzymująca się powinna być równa najwyższej tolerowanej wartości, aby móc korzystać z dzielenia na partie. | |
delivery.timeout.ms |
Ustaw zgodnie z formułą (request.timeout.ms + linger.ms) * retries. |
||
compression.type |
none |
Kompresja nie jest obecnie obsługiwana. |
Tylko konfiguracje konsumentów
Konfiguracje konsumentów można znaleźć tutaj.
| Właściwości | Zalecane wartości | Dozwolony zakres | Uwagi |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 jest wartością domyślną i nie należy jej zmieniać. | |
session.timeout.ms |
30000 | 6000 .. 300000 | Zacznij od 30000, zwiększ, jeśli występują częste ponowne równoważenie z powodu pominiętych pulsów. Upewnij się, że request.timeout.ms jest co najmniej zalecaną wartością 60000, a session.timeout.ms jest co najmniej zalecaną wartością 30000. Jeśli te ustawienia są zbyt niskie, mogą spowodować przekroczenia limitu czasu użytkownika, co spowoduje ponowne równoważenie (co powoduje większe przekroczenie limitu czasu, co powoduje ponowne równoważenie itd.). |
max.poll.interval.ms |
300000 (ustawienie domyślne) | >session.timeout.ms | Służy do ponownego równoważenia limitu czasu, więc nie należy go ustawiać zbyt nisko. Musi być większe niż session.timeout.ms. |
właściwości konfiguracji librdkafka
Główny librdkafka plik konfiguracji (link) zawiera rozszerzone opisy poniższych właściwości.
Konfiguracje producentów i konsumentów
| Właściwości | Zalecane wartości | Dozwolony zakres | Uwagi |
|---|---|---|---|
socket.keepalive.enable |
prawda | Konieczne, jeśli oczekuje się, że połączenie będzie bezczynne. Platforma Azure zamknie bezczynność > protokołu TCP dla ruchu przychodzącego 240 000 ms. | |
metadata.max.age.ms |
~ 180000 | < 240000 | Można obniżyć, aby szybciej pobierać zmiany metadanych. |
Tylko konfiguracje producenta
| Właściwości | Zalecane wartości | Dozwolony zakres | Uwagi |
|---|---|---|---|
retries |
> 0 | Wartość domyślna to 2147483647. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Usługa Event Hubs będzie domyślnie domyślna co najmniej 20 000 ms. librdkafka wartość domyślna to 5000, co może być problematyczne. Chociaż żądania z niższymi wartościami limitu czasu są akceptowane, zachowanie klienta nie jest gwarantowane. |
partitioner |
consistent_random |
Zobacz dokumentację librdkafka | consistent_random jest ustawieniem domyślnym i najlepszym. Klucze puste i null są obsługiwane idealnie w większości przypadków. |
compression.codec |
none |
Kompresja nie jest obecnie obsługiwana. |
Tylko konfiguracje konsumentów
| Właściwości | Zalecane wartości | Dozwolony zakres | Uwagi |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 jest wartością domyślną i nie należy jej zmieniać. | |
session.timeout.ms |
30000 | 6000 .. 300000 | Zacznij od 30000, zwiększ, jeśli występują częste ponowne równoważenie z powodu pominiętych pulsów. |
max.poll.interval.ms |
300000 (ustawienie domyślne) | >session.timeout.ms | Służy do ponownego równoważenia limitu czasu, więc nie należy go ustawiać zbyt nisko. Musi być większe niż session.timeout.ms. |
Dalsze uwagi
Zapoznaj się z poniższą tabelą typowych scenariuszy błędów związanych z konfiguracją.
| Objawy | Problem | Rozwiązanie |
|---|---|---|
| Błędy zatwierdzania przesunięcia z powodu ponownego równoważenia | Twój konsument czeka zbyt długo między wywołaniami poll() i usługa kopnie konsumenta z grupy. | Dostępnych jest kilka opcji:
|
| Wyjątki sieciowe o wysokiej przepływności | Czy używasz klienta Java + domyślnego max.request.size? Żądania mogą być zbyt duże. | Zobacz konfiguracje języka Java powyżej. |
Następne kroki
Zobacz Limity subskrypcji i usług platformy Azure, limity przydziału i ograniczenia dotyczące limitów przydziałów i limitów wszystkich usług platformy Azure.