Apache Kafka to platforma przesyłania strumieniowego danych odpowiedzialna za przesyłanie strumieniowe danych z wielu źródła do wielu cele. Źródła są również nazywane producenci. Opracowane dane są potrzebne zupełnie innej grupie o nazwie konsumenci do różnych celów. Kafka to warstwa, która znajduje się między producentami a konsumentami i agreguje dane w użytecznym rurociągu. Również sam Kafka jest platformą rozproszoną, więc warstwa kafka składa się z różnych serwerów z Kafka, te serwery lub węzły są zatem znane jako Kafka Brokerzy.

Ten przegląd jest nieco w abstrakcji, więc uzasadnijmy to w scenariuszu w świecie rzeczywistym, wyobraź sobie, że musisz monitorować kilka serwerów internetowych. Każda z nich prowadzi własną stronę internetową, a nowe dzienniki są stale generowane w każdym z nich co sekundę dnia. Ponadto istnieje wiele serwerów e -mail, które również musisz monitorować.

Może być konieczne przechowywanie tych danych w celu prowadzenia rekordów i rozliczeń, które jest pracą, która nie wymaga natychmiastowej uwagi. Możesz uruchomić analizy danych, aby podejmować decyzje w czasie rzeczywistym, co wymaga dokładnego i natychmiastowego wkładu danych. Nagle znajdziesz się w potrzebie usprawnienia danych w rozsądny sposób dla wszystkich różnych potrzeb. Kafka działa jak warstwa abstrakcji, do której wiele źródeł może publikować różne strumienie danych i dane konsument może subskrybować strumienie, które uzna za istotne. Kafka upewni się, że dane są dobrze uporządkowane. To wewnętrzne kafka, które musimy zrozumieć, zanim przejdziemy do tematu partycjonowania i kluczy.

Tematy Kafki, broker i partycje

Kafka Tematy są jak tabele bazy danych. Każdy temat składa się z danych z określonego źródła określonego typu. Na przykład zdrowie klastra może być tematem składającym się z informacji o procesora i pamięci. Podobnie przychodzący ruch w całej klastrze może być kolejnym tematem.

Kafka została zaprojektowana tak, aby była skalowalna w poziomie. To znaczy, pojedynczy przypadek Kafki składa się z wielu kafki brokerzy Działając przez wiele węzłów, każdy może obsługiwać strumienie danych równolegle do drugiego. Nawet jeśli kilka węzłów zawodzi, że rurociąg danych może nadal funkcjonować. Konkretny temat można następnie podzielić na wiele partycje. To partycjonowanie jest jednym z kluczowych czynników stojących za poziomą skalowalności Kafki.

Wiele producenci, Źródła danych dla danego tematu, mogą pisać jednocześnie do tego tematu, ponieważ każdy zapisuje inną partycję, w dowolnym momencie. Teraz zwykle dane są przypisywane losowo do partycji, chyba że podamy jej klucz.

Partycjonowanie i zamawianie

Aby podsumować, producenci piszą dane na dany temat. Ten temat jest faktycznie podzielony na wiele partycji. I każda partycja żyje niezależnie od innych, nawet dla danego tematu. Może to prowadzić do wielu zamieszania, gdy zamówienie do danych ma znaczenie. Może potrzebujesz swoich danych w kolejności chronologicznej, ale posiadanie wielu partycji dla danych DataStream nie gwarantuje idealnego zamówienia.

Możesz użyć tylko jednego partycji na temat, ale to pokonuje cały cel rozproszonej architektury Kafki. Potrzebujemy więc innego rozwiązania.

Klucze do partycji

Dane od producenta są wysyłane do partycji losowo, jak wspomnialiśmy wcześniej. Wiadomości to faktyczne fragmenty danych. To, co producenci mogą zrobić, oprócz wysyłania wiadomości, to dodanie klucza, który się z tym wiąże.

Wszystkie wiadomości, które są dostarczane z konkretnym kluczem, przejdą do tej samej partycji. Na przykład aktywność użytkownika można śledzić chronologicznie, jeśli dane tego użytkownika są oznaczone klawiszem, więc zawsze kończy się jednym partycją. Nazwijmy tę partycję P0 i użytkownika U0.

PARTITION P0 zawsze odbiera wiadomości związane z U0, ponieważ ten klucz łączy je. Ale to nie znaczy, że P0 jest tylko związane z tym. Może również przyjmować wiadomości z U1 i U2, jeśli ma do tego pojemność. Podobnie inne partycje mogą konsumować dane od innych użytkowników.

Punkt, w którym dane danego użytkownika nie są rozprzestrzeniane na inną partycję, zapewniając chronologiczne zamówienie dla tego użytkownika. Jednak ogólny temat dane użytkownika, nadal może wykorzystać rozproszoną architekturę Apache Kafka.

Wniosek

Podczas gdy systemy rozproszone, takie jak Kafka, rozwiązują niektóre starsze problemy, takie jak brak skalowalności lub posiadanie pojedynczego punktu awarii. Są dostarczane z zestawem problemów, które są unikalne dla własnego projektu. Przewidywanie tych problemów jest istotną zadaniem każdego architekta systemu. Co więcej, czasami naprawdę musisz przeprowadzić analizę kosztów, aby ustalić, czy nowe problemy są godnym kompromisem dla pozbycia się starszych. Zamawianie i synchronizacja to tylko wierzchołek góry lodowej.

Mamy nadzieję, że takie artykuły i oficjalna dokumentacja mogą pomóc ci po drodze.