Jak zminimalizować opóźnienia związane z kafka messaging framework?

Question

Jak zminimalizować opóźnienia związane z kafka messaging framework?

Scenariusz: mam mały temat (~150msgs/sec) dla którego chcielibyśmy mieć niskie Opóźnienie propagacji od producenta do konsumenta.

Dodałem znacznik czasu od producenta i odczytałem go u konsumenta, aby nagrać Opóźnienie propagacji, przy domyślnych konfiguracjach msg (20 bajtów) pokazało Opóźnienie propagacji od 1960ms do 1230ms. nie ma opóźnienia sieciowego, ponieważ próbowałem na 1 producencie i 1 prostym konsumencie na tej samej maszynie.

Kiedy próbowałem dostosować temat przedział spłukiwania do 20ms, spada następnie próbowałem dostosować konsumentów "fetcher.backoff.ms" do 10ms, spadł do 1070ms - 860ms.

Problem: dla 20 bajtów msg, chciałbym mieć Opóźnienie propagacji tak niskie, jak to możliwe, a ~950ms to wyższa liczba.

Pytanie: coś mi umyka w konfiguracji? Mile widziane komentarze, opóźnienia, które masz jak najmniej.

Założenie: System Kafka wymaga wejścia/Wyjścia dysku przed konsument otrzymuje msg od producenta, a to idzie z RPM dysku twardego i tak dalej..

Update : Próbowałem dostroić politykę log Flush pod kątem trwałości i opóźnienia.
poniżej znajduje się konfiguracja:

# The number of messages to accept before forcing a flush of data to disk
log.flush.interval=10
# The maximum amount of time a message can sit in a log before we force a flush
log.default.flush.interval.ms=100
# The interval (in ms) at which logs are checked to see if they need to be 
# flushed to disk.
log.default.flush.scheduler.interval.ms=100

Dla tego samego msg 20 bajtów opóźnienie wynosiło 740ms-880ms.

Poniższe instrukcje są jasno określone w samej konfiguracji.
jest kilka ważnych kompromisów:

trwałość : Brak danych jest na większe ryzyko utraty w przypadku awarii.
opóźnienie : Dane nie są udostępniane konsumentom, dopóki nie zostaną spłukane (co dodaje opóźnienie).
przepustowość : płukanie jest zwykle najdroższą operacją.

Więc, uważam, że nie ma sposobu, aby zejść do znaku 150ms - 250ms. (bez aktualizacji sprzętu) .

23

apache-kafka

Author: Amol M Kulkarni, 2013-12-11

Source

4 answers

Wiem, że minęło ponad rok od tego pytania, ale właśnie zbudowałem Klaster Kafka dla celów programistycznych i widzimy opóźnienie

Mierzę opóźnienie uruchamiając producenta Javy i konsumenta, który napisałem. Oba działają na tej samej maszynie, na czwartej maszynie wirtualnej w tym samym środowisku Skytap (aby zminimalizować opóźnienia sieci). Producent zapisuje bieżący czas (System.nanoTime()), używa tej wartości jako ładunku w wiadomości Avro i wysyła (acks=1). Konsument jest skonfigurowany do ciągłego badania z limitem czasu 1ms. Gdy otrzyma partię wiadomości, ponownie zapisuje bieżący czas (System.nanoTime()), a następnie odejmuje odbieraj czas od czasu wysłania, aby obliczyć opóźnienie. Gdy ma 100 wiadomości, oblicza średnią wszystkich 100 opóźnień i wypisuje na stdout. Należy pamiętać, że ważne jest, aby uruchomić producenta i konsumenta na tej samej maszynie, aby nie było problemu z synchronizacją zegara z obliczaniem opóźnienia.

Grałem trochę z ilością wiadomości generowanych przez producenta. Jest zdecydowanie punkt, w którym jest ich zbyt wiele i opóźnienia zaczynają wzrastać, ale jest znacznie wyższy od czasu do czasu przesyłanie wiadomości zajmuje nawet 20 ms, ale zdecydowana większość to od 0,5 ms do 1,5 ms.

Wszystko to zostało osiągnięte dzięki domyślnym konfiguracjom Kafka 0.9. Nie musiałem nic poprawiać. Użyłem batch-size = 1 do moich początkowych testów, ale okazało się później, że nie miało to wpływu na niską głośność i nałożył znaczny limit na głośność szczytową, zanim opóźnienia zaczęły rosnąć.

Ważne jest, aby pamiętać, że kiedy prowadzę mojego producenta i konsumenta na moim lokalnym komputerze dokładnie ta sama konfiguracja zgłasza opóźnienia w zakresie 100ms - dokładnie te same opóźnienia zgłaszane, jeśli po prostu ping moich brokerów Kafka.

Edytuję tę wiadomość później z przykładowym kodem od mojego producenta i konsumenta wraz z innymi szczegółami, ale chciałem coś opublikować, zanim zapomnę.

11

Author: JakeRobb,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-01-25 14:46:20

Współczesne wersje Kafki wydają się mieć dość minimalne opóźnienie, ponieważ wyniki z tutaj pokazują:

2 ms (mediana) 3 ms (99. percentyl) 14 ms (99,9 percentyla)

4

Author: Ravi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-01-28 20:11:11

Kafka może osiągnąć około milisekundowe opóźnienie, używając synchronicznego przesyłania wiadomości. Przy synchronicznym wysyłaniu wiadomości producent nie zbiera wiadomości do łatki przed wysłaniem.

bin/kafka-console-producer.sh --broker-list my_broker_host:9092 --topic test --sync

Następujący efekt ma taki sam:

--batch-size 1

3

Author: Jack,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-05-21 05:47:55

score 30 · Accepted Answer

Nie próbuję uniknąć pytania, ale myślę, że kafka jest złym wyborem dla tego przypadku użycia. Chociaż uważam, że Kafka jest świetna (byłem wielkim zwolennikiem jej wykorzystania w moim miejscu pracy), jego długość nie jest niska latencja. Jej atutami są wysoka wydajność produkcyjna i wsparcie zarówno dla szybkich, jak i powolnych konsumentów. Chociaż zapewnia trwałość i odporność na uszkodzenia, podobnie jak systemy bardziej ogólnego przeznaczenia, takie jak rabbitMQ. RabbitMQ obsługuje również wiele różnych klientów, w tym node.js. Gdzie rabbitMQ w porównaniu do Kafki jest krótki, gdy masz do czynienia z bardzo dużymi objętościami (powiedzmy 150K msg / s). W tym momencie podejście królika do trwałości zaczyna się rozpadać, a Kafka naprawdę się wyróżnia. Wytrzymałość i odporność na uszkodzenia królika są więcej niż zdolne przy 20K msg / s (z mojego doświadczenia).

Również, aby osiągnąć tak wysoką przepustowość, Kafka zajmuje się wiadomościami partiami. Chociaż partie są małe, a ich rozmiar można konfigurować, nie można ich również małe bez ponoszenia dużych kosztów. Niestety, przesyłanie wiadomości sprawia, że niskie opóźnienia są bardzo trudne. Chociaż możesz dostroić różne ustawienia w Kafce, Nie używałbym Kafki do niczego, gdzie opóźnienie musiało być mniej niż 1-2 sekundy.

Również kafka 0.7.2 nie jest dobrym wyborem, jeśli uruchamiasz nową aplikację. Teraz skupiamy się na 0.8, więc będziesz zdany na siebie, jeśli napotkasz problemy i na pewno nie spodziewałbym się żadnych nowych funkcji.

Znowu Ja myślę, że Kafka jest świetna do niektórych bardzo specyficznych, choć popularnych przypadków użycia. W moim miejscu pracy używamy zarówno królika, jak i Kafki. Chociaż może się to wydawać bezinteresowne, oni naprawdę są uprzejmi.