RabbitMQ & Kafka Flashcards
Czym jest RabbitMQ
- message broker
- komunikacja asynchroniczna pomiędzy serwisami
- przyjmuje i przekazuje wiadomości pomiędzy usługami
- używa protokołu AMPQ
- RabbitMq jest jak skrzynka pocztowa, poczta oraz dostawca
Producer
- jest to program , który tworzy i wysyła wiadomości
- określa routing key, który jest używany do dalszego kierowania wiadomośći
Kolejka
- miejsce gdzie wiadomości są przechowywane i czekają na odebranie przez konsumentów
- Producenci mogą dodawać wiadomości do kolejki bez potrzeby bezpośredniego połączenia z konsumentami.
- mogą łagodzić chwilowe szczyty obciążenia przez buforowanie nadmiernego ruchu
- kolejki mogą gwarantować dostarczenie wiadomości nawet w przypadku tymczasowej niedostępności konsumentów
- Skalowalność - mogą obsłużyć rosnący przepływ danych poprzez dodawanie więcej konsumentów bez zmiany logiki producentów.
Consumer
- program oczekujący na wiadomość
Round robin dispatching
- algorytm używanych w kolejkach
- rozdziela równomiernie odbiorców
- przesyła kolejno każdą nową wiadomość do następnego konsumenta w sekwencji.
- każdy konsumenci otrzymuje mniej więcej taką samą liczbę wiadomości.
- nie zawsze jest idealny, jeśli zadania mają różny czas przetwarzania.
Message acknowledgment
- informuje kolejkę, że dana wiadomość została odebrana i odpowiednio przetworzona przez konsumenta
- jeśli potwierdzenie nie zostanie odesłane to wiadomość zostanie wysłana ponownie
- wiadomość nie zostatnie stracona
- można ustawić automatyczne powtwierdzenia po wysłaniu
- można ustawić manulane - po potwierdzeniu wiadomość zostanie usunięta
Message durability
- zdolności systemu do zachowania wiadomości nawet w przypadku awarii
Fair dispatch
- techniki rozdzielania zadań pomiędzy różne pracownicze procesy (consumers) w sposób bardziej równomierny
- Celem tej techniki jest zapobieganie przeciążaniu niektórych pracowników, podczas gdy inni mają niewiele lub nic do zrobienia.
- Gdy pre-fetch count jest ustawiony na 1, RabbitMQ nie będzie wysyłał nowej wiadomości do pracownika, dopóki ten nie przetworzy i nie potwierdzi poprzedniej,
Competing Consumer pattern
Exchange
- węzeł komunikacyjny, który przyjmuje wiadomości od producentów (producers) i przekierowuje je do kolejek według określonych reguł
- Kiedy producent wysyła wiadomość do exchange, nie wie, do której kolejki wiadomość zostanie ostatecznie dostarczona.
- działa według określonego typu np. direct, topic, fanout, headers
exchange type
- określa w jaki wymiana (exchange) przekierowuje wiadomości do kolejek na podstawie informacji, które zawiera wiadomość :
- routing key)
- binding rules)
Typy exchange type
- direct
- topic
- headers
- fanout
Binding
- relacja pomiędzy exchange a queue
- jak most
- określa jak wiadomości trafiają z wymiany do kolejki
Publish/Subscribe
- publisher wysyła wiadomośc do wymiany, nie wiedząc kto , lub ile odbirców otrzyma tę wiadomość
- subskrybowanie zapisują sie do otrzymywania wiadomości z określonej kolejki
- idealny do rozglaaszania informacji do wielu odbirców gdzize komunikacja jest jednokierunkowa
- subskrybenci mogą dynamicznie dołączac lub opuszczać system
Direct Exchange
- używa routing key
- ## wiadomośc jest wysyłana do kolejek z binding key pasującym do routing key wiadmości
Fanout Exchange
- nie używa routing key
- wysyła wiadomości do wszystkich związanych kolejek
Topic exchange
- wiadomości są routowane do kolejek na podstawie wzorca w routing key
-
*
zastępuje dokladnie jednen wyraz -
#
zatępuje zero lub więcej wyrazów - z użyciem wzorców kolejki mogą subskrybować róże typy wiadmości
Jak działa Topic Exchange
- Wiadomość jest wysyłana do Topic Exchange z określonym** routing key (np. auth.error).**
- Exchange porównuje klucz routingu z wzorcami związanymi z kolejnymi (bindings) i decyduje, do których kolejek przekazać wiadomość.
- Jeśli binding pasuje, wiadomość jest kierowana do odpowiedniej kolejki.
- Consumer nasłuchujący na danej kolejce odbiera wiadomość i może ją przetworzyć.
Pattern **<speed>.<colour>.<species>**</species></colour></speed>
Na jaką kolejkę trafi wiadomość z routing key
quick.orange.rabbit
Q1 I Q2
Routing key
- atrybut, która producer przypisuje do wiadomości aby wymiana mogła użyc zasad routingu, by określic do której kolejki wiadomośc powinna zostać wysłana
Kafka vs RabbitMQ
Kafka:
- przetwarzanie strumieniowe, event streaming model
- bardzo dobrze się skaluje horyzontalnie - do większego przeływu wiadomości
- wysoka przepustowość
- wiadomości zapisywane na dyskach
- posiada pełen log zdarzeń
- logowanie zdarzeń w czasie rzeczywistym
RabbitMq
- skoncentrowany na przesyłaniu wiadomości i kolejkowaniu
- obsługuje różne wzroce komunikacji, bardziej skomplikowany routing
- nie jest tak wydajny jak Kafa - lepszy do komunikatów
- potwierdzenia wiadomości
Event Drive Architecture
- przepływ danych i komunikacja między usługami są sterowne przez zdarzenia
- generowanie i reagowanie na zdarzenia jest podstawą działania aplikacji
- asynchroniczna komunikacja
- data conistancy
- Producter -> Event Bus (even channgels) -> Consumer
- **Publisher/Subscriver Model - RabbitMq
- ## Event Streaming Model - Kafka**
Zalety EDA
- decoupling
- skalowalność (bo decoupled)
- asynchronicznośc, reposonsywność
Kafka
- system przesyłania wiadomości
- platforma przetwarzania strumieniowego
- duża ilość danych w czasie rzeczywistym
- skalowania w poziomie
- przechowuje strumienie danych na dyskach
- wysoka przepustowość
Broker Kafka
- serwer który przechowuje dane
- obłsuguje zapytania od producerów i konsumentów
- może mieć jakąkolwiek liczbe tematów
- kafka działa zazwyczaj jako klaseter złożony z wielu brokerów,producentów i brokerów aby zapewnić skalowalności i odporność na awarie,
Topic Kafka
- kategorie do których producenci wysyłaja wiadomości
- konsumenci subskrybują
- podzielane są na partycje co umożliwa rónoległe przetwarzanie i zwiększa przepustowość
Partycje Kafka
- kązdy temat w Kafce może być podzielony na wiele partycji
- umożliwają równoległe przetwarzanie danych
- przechowują dane
- używają offestów do identyfikacji wiadomości
Replikacja Kafka
- kafka replikuje dane między brokerami w celu zapewnienia wysokiej dostępności i odporności na awarie
Offest
- używane jako identyfikator wiadomości w każdej partycji
- konsumenci kontroluj swój offset i mają możliwość przeskoczyć ale skipnąć wiadomość
Producers Kafka
- wysyłaja wiadomości do Kafka Topic
- kafka zapisuje te wiadomości w topic log
Consumer
- odczytują wiadomości z topic
- subskrybują jeden lub więcej topików
- czytają wiadomości z partycji z topicu
- używają offsetu do śledzenia progresu w topicu
Producer Side stroy
- Koniguracja - kafka broker adres, serialization format
- Wybór topicu jeśli nie ma zostanie stworzony dynamicznie
- Tworzenie wiadomości wybiera target topic, i serialized message, opcjonalnie parition key aby kontrolować do której partycji trafi
- Przypisanie partycji - jest nie ma partion key to użyje Round robin albo hashing algorithm
- Routing, przypisanie offsetu wyśle wiadomośc do brokera, topicu, partycji. Broker zapisze wiadomośc w logu tej partycji razem z offset id
- Replikacja wiadomości - zapewnie wysokiej dostępności i odporności
- Powiadomonie o wysłaniu
Consumer Side
- Consumer Group, Topic Subscribtion - dołączają do grup i subskrybują topic
- Przypisanie do partycji kafka przypisuje każdą partycję do jednego konsumenta. Zapewnia równą dystrybujce
- Zarządzanie offsetem - konsument zarządza offsetem aby śledzić progres odczytu
- Wysyła Fetch Request do brokera z informacja o topic, partition i offset. Określa również ile wiadomości naraz możę pobrać.
- Pobieranie wiadomości Kafka pobieranie wiadomości z partition log i przesyła do consumera w odpowiedzi na fetch reposne
- Procesowwanie wiadomośći przez konsumenta
- Przesłanie offsetu - po przetworzeniu konsumer musi wysłać offset do Kafki. Ozancza to, że przeprocesował wiadomość i może rozpocząc od tego miejsca.
- Pętla
Zalety RabbitMq
- zapewnia trwałość wiadomości - przetrwają restart serwera
- wspiera potwierdzenia wiadomości
- elastyczny routing wiadomości
- można skalować , przepustowość
- monitoring i zarządzanie, - interfejs
Request/Reply pattern
- Requester tworzy wiadomość
- ustawia nazwę trzymaczasowej kolejki na replyTo gdzie oczekuje odpowiedzi
- ustawia correlationId dla danego zapytania
- Replier nasłuchuje requestQeue
- otrzymuje i generuje odpowiedz
- wysyła odpowiedz do kolejki replyTo
- dołącza correlationId aby klient mógł zidentyfikować
QoS
- RabbitMQ pozwala na kontrolowanie ilości wiadomości, które konsument może przetwarzać na raz, poprzez ustawienie parametru QoS (prefetch count).
- Ustawienie niskiego prefetch count może pomóc w równomierniejszym rozdzieleniu obciążenia, szczególnie gdy czas przetwarzania wiadomości jest zróżnicowany
Czy rabbit może zapisywać wiadomości ?
- można określić, że wiadomość jest trwała co oznacza, że rabbit zapisze je na dysk
- jeśli kolejka jest trwała to również zostaną po restarcie serwera (zapisywane na dysk)
Publisher Confirms
- umożliwia producentom otrzymywanie od brokera potwierdzeń, że wiadomopść została poprawnie odebrana i przetworzona przez RabbitMq
- producent musi włączyć potwierdzenia publikacji na kanale, z którym się komunikuje
- po zapisaniu wiadomości w trwałej kolejsce, rabbit wysyła potwierdzenie do producenta
- może być ack lub nack
Kanały
- używane do wysyłania i odbierania wiadomości
- kazdą operacja publikowania i konsumowania odbywa się przez kanał
- deklaracje kolejek wymian bindingów również przez kanal
z czego składa się wiadomość