Czy Apache Kafka jest odpowiedni do użycia jako kolejka zadań?

Question

Kafka dzieli wiadomości przychodzące na partycje zgodnie z partycją przypisaną przez producenta. Wiadomości z partycji są następnie konsumowane przez konsumentów w różnych grupach konsumenckich.

Architektura ta sprawia, że ​​obawiam się używania Kafki jako kolejki zadań/zadań, ponieważ muszę określić partycję w momencie produkcji, co pośrednio ogranicza liczbę klientów, którzy mogą na niej pracować, ponieważ partycja jest wysyłana tylko do jednego konsumenta. grupa konsumencka. Wolałbym nie określać partycji z wyprzedzeniem, aby mógł to zrobić dowolny klient dostępny do wykonania tego zadania. Czy istnieje sposób na uporządkowanie partycji/producentów w architekturze Kafki, w której zadania mogą zostać przyciągnięte przez następnego dostępnego konsumenta, bez konieczności dzielenia pracy z wyprzedzeniem, wybierając partycję podczas produkcji?

Używanie tylko jednej partycji do tego tematu spowoduje, że wszystkie zadania będą w tej samej kolejce, ale wtedy liczba konsumentów jest ograniczona do 1 na grupę konsumentów, więc każdy konsument musiałby być w innej grupie. Następnie wszystkie zadania są dystrybuowane do każdej grupy konsumenckiej, co nie jest rodzajem oczekującej pracy, której szukam.

Czy Apache Kafka jest odpowiedni do użycia jako kolejka zadań?

Answer 1

Używanie Kafki do kolejki zadań jest złym pomysłem. Używaj RabbitMQ zamiast tego, robi to znacznie lepiej i bardziej elegancko.

Chociaż można użyć Kafki do kolejki zadań - otrzymasz kilka problemów: Kafka nie pozwala na konsumpcję pojedynczej partycji przez wielu klientów (według projektu), więc jeśli na przykład jedna partycja zostanie wypełniona wieloma zadaniami a konsument, który jest właścicielem partycji, jest zajęty, zadania w tej partycji zostaną "głodzone". Oznacza to również, że kolejność konsumpcji zadań w temacie nie będzie taka sama jak kolejność, w której zostały wykonane zadania, co może spowodować poważne problemy, jeśli zadania muszą zostać spożytkowane w określonej kolejności (w Kafce, aby w pełni osiągnąć to musi mieć tylko jednego konsumenta i jedną partycję - co oznacza zużycie seryjne tylko przez jeden węzeł. Jeśli masz wielu klientów i wiele partycji, kolejność wykonywania zadań nie będzie gwarantowana na poziomie tematu).

Tak naprawdę - tematy Kafki nie są kolejkami w informatyce. Kolejka oznacza First in First out - to nie jest to, co dostajesz w Kafce na poziomie tematu.

Inną kwestią jest to, że trudno jest dynamicznie zmieniać liczbę partycji. Dodawanie lub usuwanie nowych pracowników powinno być dynamiczne. Jeśli chcesz mieć pewność, że nowi pracownicy otrzymają zadania w Kakfa, musisz ustawić numer partycji na maksymalną możliwą liczbę pracowników. To nie jest wystarczająco eleganckie.

Więc dolna linia - zamiast tego użyj RabbitMQ lub innych kolejek.

Powiedziawszy to wszystko - Samza (przez LinkedIn) korzysta Kafka jako pewnego rodzaju strumieniowe oparte kolejce zadanie: Samza

Answer 2

Powiedziałbym, że to zależy od skali. Ile zadań przewidujesz w jednostce czasu?

To, co określasz jako cel końcowy, to w zasadzie to, jak Kafka działa domyślnie. Kiedy tworzysz wiadomości, domyślną (najczęściej używaną) opcją jest użycie losowego partycjonera, który wybiera partycje w trybie round robin, utrzymując równomiernie używane partycje (dzięki czemu można uniknąć określania partycji).
Głównym celem partycji jest równoległe przetwarzanie komunikatów, więc należy go używać w taki sposób.
Inną powszechnie używaną "rzeczą", której używa się partycji, jest zapewnienie, że niektóre wiadomości są zużywane w tej samej kolejności, w jakiej zostały wyprodukowane (następnie należy określić klucz partycjonowania w taki sposób, aby wszystkie takie wiadomości trafiały do ​​tej samej partycji. użycie userId jako klucza zapewniłoby, że wszyscy użytkownicy są przetwarzani w taki sposób).

Answer 3

Istnieją dwie główne przeszkody próbuje użyć Kafkę jako kolejki komunikatów:

1. jak opisano w Ofer's answer można spożywać tylko jedną partycję z jednego konsumenta, a kolejność przetwarzania jest gwarantowana tylko w partycji. Jeśli więc nie możesz sprawiedliwie rozdzielić zadań między partycje, może to być problem. Domyślnie można potwierdzić przetwarzanie wszystkich komunikatów do określonego punktu (przesunięcie). W przeciwieństwie do tradycyjnych kolejek wiadomości, nie można dokonywać selektywnego potwierdzenia, aw przypadku niepowodzenia, próbować ponownie. Może to być adres przy użyciu kmq, który dodaje funkcje pojedynczych plików za pomocą dodatkowego tematu (zrzeczenie się: Jestem autorem kmq).

RabbitMQ jest alternatywne oczywiście, ale także daje inną (niższą) wydajnością i replikacji gwarancje. W skrócie, dokumenty RabbitMQ mówią, że broker is not partition tolerant. Zobacz także nasze porównanie kolejek komunikatów z replikacją danych, mqperf.