Tworzenie systemu powiadamiania push w czasie rzeczywistym dla aplikacji komputerowych/mobilnych/internetowych przy użyciu kafka jako brokera komunikatów

Question

Mam przypadek użycia, w którym musi istnieć komunikacja w czasie rzeczywistym między serwerami i klientami w czasie rzeczywistym, zgodnie ze wzorcem powiadamiania pub/sub . Producenci będą serwerami w java, węźle itd. I klientami będą: java aplikacje komputerowe, aplikacje mobilne (android/ios), przeglądarka (javascript).

Zbadałem wiele opcji omówionych poniżej, ale nie jestem w stanie wymyślić potężnego skalowalnego rozwiązania.

Przypadek użycia: Serwer będzie publikował powiadomienia/wiadomości na różne tematy, a wszyscy klienci (java/js/ios) subskrybujący zbiór tematów otrzymają te wiadomości w czasie rzeczywistym.

Podążyłem za 3 podejściami, aby rozwiązać ten problem 1> socketIo/socketcluster 2> zbadał protokół mqtt z komendą mosquitto/rabbitmq jako brokerem. 3> zbadane kafka

Głównym celem jest uczynienie tej architektury wysoce skalowalną, z nie tylko ponad milionem jednoczesnych połączeń z klientami, ale także z ponad milionem wiadomości publikowanych i zużywanych na sekundę.

Pierwsze podejście jest proste i działa, ale webSocket nie jest skalowalnym rozwiązaniem.

Drugie podejście działa, ale rabbitmq utworzy dużą liczbę kolejek (miliony kolejek na milion klientów), ponieważ utrzymuje kolejki dla każdego klienta podłączonego do niego, także rabbitMq nie ma wysokiego wskaźnika publikowania i konsumowania, powiedzmy, powiedzmy mamy klaster węzłów rabbitMq, tylko jeden węzeł jest używany do obsługi żądań, a inne są używane do wysokiej dostępności, ale nie do równoległej konsumpcji.

Po trzecie zbadałem kafkę, która jest znana z benchmarków. Tworzyłem klientów w Javie, używając wysokiej klasy aplikacji java api, która może być użyta do zasubskrybowania tematu kafka, a każda wiadomość opublikowana w tym temacie jest dostarczana klientowi w rzeczywistości. czas.

Więc moje pytanie brzmi, jak dobrze jest używać klientów kafka dla powiadomień push w czasie rzeczywistym, gdzie wszystkie aplikacje na komputery java (może milion) będą zawierały ten klient kafki Java i będą subskrybować pewne tematy, tutaj traktuję każdego klienta jako grupę konsumentów.

Jednym z głównych problemów jest to, że ten klient kafka ma duży rozmiar ze względu na zależności scala, więc użycie tego klienta w systemie Android nie będzie dobrym rozwiązaniem, ale nie sądzę, że będzie działało.

mqtt przoduje tutaj jak to ma oficjalnych klientów Phao dla Android, Java, iOS itp

Również nie widziałem przykładami internecie przy użyciu Kafkę na pub/sub wiadomości z milionami konsumentów, głównie osób używa go do przesyłania danych, np .: przetwarzanie dziennika w czasie rzeczywistym, przesyłanie danych do HDFS, silnik analityczny itp., przetwarzanie strumieniowe.

Głównym pytaniem jest to, w jaki sposób można wykorzystać protokół mqtt (który dobrze współpracuje z systemem Android/iOS/web/Internet przedmiotów) z Kafka jako broker wiadomości (który ma wysoki publikować/stawka subskrybować) i pochodzą z skalowalne rozwiązanie tego problemu.

Mój przypadek użycia przypomina również uber, gdzie jest milion urządzeń z Androidem i ios (klientów) i możemy zobaczyć ruch w czasie rzeczywistym wszystkich samochodów w naszej lokalizacji na mapie, czy ktoś ma pomysł, że jaka jest architektura stojąca za śledzeniem samochodów w czasie rzeczywistym.

Answer 1

This article opisuje tworzenie systemu czatowania w czasie rzeczywistym za pomocą Kafki i node.js. Łączą się również z git repo zawierającym ich przykład. Oto coś pamiętać z artykułu:

Podczas testów zauważyliśmy, że istnieje około 1sek z opóźnieniem między zamieszczając wiadomość i pojawiające się na wszystkich innych klientów, co Doszliśmy się było ze względu na to, jak często Kafka przekazuje wiadomości na dysk. Ponieważ Kafka zapewnia, że ​​wiadomości nie zostaną zgubione, muszą zostać zapisane na dysku zanim zostaną przekazane subskrybentom. Twórcy mają wybraną do wypróżniania wiadomości na dysk co sekundę, co wyjaśnia opóźnienie , które widzieliśmy.

Uważamy, że jest to interesujący sposób robienia rzeczy, ale robi się to zadanie . Jak zauważają, nacisk kładziony jest na przepustowość, a nie opóźnienie, więc gdy nie jest idealnie dopasowany do tego rodzaju użytkowania, wykonuje się zadanie .