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 bezczynność > protokołu TCP (Bound Transmission Control Protocol) 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 zamyka połączenia, jeśli wysyłane są żądania większe niż 1046 528 bajtów. Ta wartość musi zostać zmieniona i powoduje 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 wewnętrznie domyślnie wynosi 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 |
uncompressed, gzip |
Obecnie obsługiwana jest tylko kompresja gzip. |
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 właściwości opisanych w poniższych sekcjach.
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 zamyka przychodzący bezczynność > protokołu TCP 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 wewnętrznie domyślnie wynosi 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, gzip |
Obecnie obsługiwana jest tylko kompresja gzip. |
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 | Jeśli używasz klienta Java + domyślnego parametru max.request.size, żądania mogą być zbyt duże. | Zobacz konfiguracje języka Java wymienione wcześniej. |
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.