login::
pass::
name::
id::
node:
kanon na vrabce ?
template:
4
parent:
Apache Kafka
owner:
Prospero
viewed by:
created:
15.11.2022 - 16:37:34
cwbe coordinatez
:
101
63540
63542
63747
9018633
9018872
ABSOLUT
K
YBERIA
permissions
you:
r,
system:
public
net:
yes
⠪
neurons
stats
|
by_visit
|
by_K
source
tiamat
K
|
my_K
|
given_K
last
commanders
polls
total descendants::10
total children::2
show[
2
|
3
]
flat
v prvom rade gratulujem. znie to cele dost komplexne ;)
v druhom rade by ma celkom zaujimal konkretny use case
title/content
title
content
user
00000101000635400006354200063747090186330901887209052426
ulkas
30.03.2023 - 09:04:03
(modif: 30.03.2023 - 09:06:22), level: 1,
UP
NEW
!!CONTENT CHANGED!!
Re: kanon na vrabce ?
use case je nativne pre event based architekturu.
a druha vec je ze kafku nasadzujes do masivne distribuovaneho prostredia. my sme takto riesili problemy disaster recovery, kde nam aplikacia sedela v roznych datacentrach, v kazdom mala rozne vela instanci (autoscaler podla potreby), potrebujes byt fault tolerant, a to vsetko tak, aby si si nekafral do kapusty - aby ti instancie aplikacie navzajom nepocitali to iste a netrigerovali rovnake eventy.
a ako bonus brutalny throughput ked vies spracovat petabajt dat denne doslova "na kolene".
00000101000635400006354200063747090186330901887209019069
DreeStyler
16.11.2022 - 12:09:43
[
5K
] , level: 1,
UP
NEW
Re: kanon na vrabce ?
Vdaka, ved som za ten cas stihol aj 2x vyhoriet(riesil som este dalsie 2 subprojekty subezne a este robil Linux admina).
Kafka je na messaging. Taka vodárenská sieť na JSON/textove spravy.
Konkretny usecase su bankomatove karty a operacie pocas a po platbe kartou. U nas sa to pouziva minimalne na "bodiky zbierate" zakaznicke konta. Zakaznik prilozi kartu na terminal -> prebehne proces platby -> autorizacie od VISA/MC -> prachy sa zablokuju na karte -> obchodnik dostane prachy.
Kafkove moduly si potom nezavysle na tomto procese vytiahnu z DB konkretne info a nechavaju ich dostupne v Kafkovi pre ine aplikacie "na potom" bez narusenia platobneho procesu. Tato filozofia sa vola decoupling - rozviazanie uzkeho spojenia dvojic(DB -> Kafka a Kafka -> client) na to, aby sa vyhlo strate dat pri timoutoch, sietovych problemoch a setrili sa spojenia, kedze "bodiky zbierate" nieje az take dolezite mat hotove v realnom case na rozdiel od samotnej platby.
Dalsi klienti, napr. banka, si moze v uzkej dvojici Moja Kafka -> Ich Kafka vytiahnut rovnake data a robit si programy na spracovanie, napr. webgui, kde si moze zakaznik sledovat historiu platieb. Tym, ze je Kafka extremne rychla(kvoli priamemu pouziti volani kernelu pre sietovku a diskove operacie - sietovka priamo zapisuje na disk), tak si moze tie iste data vycitavat backend pre webgui obsluhujuci 10tis uzivatelov naraz.
Konkretnejsie:
Mas napr. Oracle DB a aplikaciu, ktora potrebuje data z DB. Kafka Connect ma modul OJDBC. Zapnes kafka connector, ktory si otvori trvale spojenie do DB a kazdych 5s posle dotaz. Ak su nove zaznamy, conector tie zaznamy nacita z DB a produkuje do Kafku. Ked uz to v Kafkovi je, tak hocjaky pocet konzumerov moze tieto spravy odobrat. Napr. Cckova kniznica Librdkafka je pouzita v C++ programe pre klientov banky, aby skonzumoval nove spravy z Kafku a klientovi vypisal ich obsah, alebo poslal SMSku. Kafka sa pritom stara o to, aby konzumujuci client dostal vzdy vsetky spravy a len raz(idempotencia), teda odlahcuje samotnu aplikaciu o kontroly celistvosti a kontrolnu logiku a tiez odlahci DB.
Kafka pri spravnom nastaveni garantuje, ze cokolvek tam pride, tak bude citatelne, ze rovnaky vstup da vzdy rovnaky vystup(idempotencia), ze poradie prichodzich a odchodzich sprav je nemenne, ze pri vypadku 1 z 3 datacentier budu vzdy data dostupne zo zvysnych 2(clustrove quorum, leaders atd), horizontalna skalovatelnost(mozes pocas behu pridavat n dalsich nod), rolling update. Navrhnute tak, ze ked sa to raz dobre nakonfiguruje a zapne, tak to ma bezat 10 rokov dokial sa to nevypne.
Filozofia je tu:
https://uloz.to/file/g8NpMRZa5DV8/designing-event-driven-systems-for-streaming-services-with-apache-kafka-ben-stopford-2018-o-reilly-20220311-eb-pdf#!ZGpjZmR2Zwt5BQZmL2MzBQHmLJL3ZwuJEQIDFKcKBUbhHGMyAD==
Konkretna realizacia je tu(treba sa zaregistrovat na stiahnutie):
https://www.confluent.io/resources/kafka-the-definitive-guide-v2/?utm_medium=sem&utm_source=google&utm_campaign=ch.sem_br.nonbrand_tp.prs_tgt.content-search_mt.xct_rgn.emea_lng.eng_dv.all_con.ktdg-v2&utm_term=kafka%20the%20definitive%20guide&creative=&device=c&placement=&gclid=EAIaIQobChMIxdzl88ey-wIVsI9oCR1jXQyYEAAYASAAEgIRMPD_BwE
0000010100063540000635420006374709018633090188720901906909052430
ulkas
30.03.2023 - 09:10:05
[
1K
] , level: 2,
UP
NEW
Re[2]: kanon na vrabce ?
hehe, ta garancia poradia nie je taka easy. da sa to garantovat len na particiu, tj default ak mas topic s 1 particou, tak order vies garantovat. sranda nastane, ak mas tak 90 particii. tam uz ten order potrebujes prehnat cez dalsi level
000001010006354000063542000637470901863309018872090190690905243009052514
DreeStyler
30.03.2023 - 13:43:29
, level: 3,
UP
NEW
Re[3]: kanon na vrabce ?
Ordering fakt nieje easy. Pochopil som to az tak v 50% projektu, ked si zacali DEVs stazovat, ze to je rozhadzane. Trebalo mat v poradi aspon male zhluky operacii(napr. ked zakaznik pri platbe urobil storno a potom znovu zaplatil to muselo byt v poradi).
Nakoniec som pouzil ordering podla kluca na vstupe do topic, tzn. spravy, ktore maju byt podla poradia, maju rovnaky kluc a ak maju rovnaky kluc, musia byt zapisane a citane z 1 particie. Stacilo pridat 1 riadok do config. DEVs a ja sme na to prisli v rovnaky cas.
0000010100063540000635420006374709018633090188720901906909019531
Prospero
18.11.2022 - 15:55:50
, level: 2,
UP
NEW
klobuk dole
s tym vyhoretim sa Ti nedivim
aspon dufam ze si to nemusel riesit v time s bandou kretenov, nieco take by minimalne mna doviedlo priamo na "oddelenie"
a verim ze Ti za to aspon adekvatne zaplatili
000001010006354000063542000637470901863309018872090190690901953109019554
DreeStyler
18.11.2022 - 18:55:31
, level: 3,
UP
NEW
Re: klobuk dole
Spolupracovnici boli nastastie v pohode, moc tomu nerozumeli, co mohli, to spravili, vsetko fajn ludia. Potom mi dali pristup na skoro uplne vsetko, tak som si to robil sam. Akurat jeden sefik si neuvedomoval rozsah toho, co vsetko som robil, tak sa spraval obcas jak curak.
Prave tie prachy boli problem - ked som videl, aky zahul to je a kam ma to privedie, tak som sa chcel dohodnut na bonusoch za projekt a aby boli papiery, co mi odmietli, takze od aprila som pracoval 8-16hod/tyzden(takze 3-4 vyplaty mam za nic) a ked som sa dal ako tak dokopy a odpocinul si, tak som tento pondelok dal vypoved a este aspon tak 2-3 mesiace a budem ok.
00000101000635400006354200063747090186330901887209019069090195310901955409020090
shady
21.11.2022 - 21:31:02
, level: 4,
UP
NEW
Re[2]: klobuk dole
Ma to po tebe kto spravovat?
0000010100063540000635420006374709018633090188720901906909019531090195540902009009020281
DreeStyler
22.11.2022 - 14:55:16
[
1K
] , level: 5,
UP
NEW
Re[3]: klobuk dole
Ma. Kolega, ktory nastupil pred 8 mesiacmi a ktory to dodnes studuje to po mne preberie. Akurat ze ked som odmietol pracovat ako Linux admin(aby som mal cas na Kafku), tak prebral po mne adminovanie a nemal na Kafku velmi cas. Este do toho stihol spravit minimalne celoprojektovy Prometheus monitoring(nic zlozite, len kopiroval exportery a otvaral porty, ale ajtak velky kus prace) a nejake clustrovanie a docker veci.
Kafku urcite zvladne, lebo ja som to urobil tak, ze najblizsi rok na tom nebude treba robit vobec nic. Este keby som to stihol zansiblit, ako som planoval, tak by to bolo uz fakt easy.
0000010100063540000635420006374709018633090188720901906909019092
lmsr
16.11.2022 - 13:07:48
(modif: 16.11.2022 - 13:20:55) [
1K
] , level: 2,
UP
NEW
!!CONTENT CHANGED!!
Re[2]: kanon na vrabce ?
"aby konzumujuci client dostal vzdy vsetky spravy a len raz(idempotencia)" Toto nie je pravda. Idempotencia je nieco ine. Je to vlastnost, ze ak aplikujes nejake zmeny raz, alebo viac krat, tak vysledok je taky, ako keby si ich aplikoval iba raz. Kafka bola povodne nadesignovana tak, ze garantovala "at least once" delivery spravy, lebo ine sposoby dorucenia sprav je tazsie naprogramovat, ak skalujes cez mrde nod. Preto musia byt aplikacie pri takomto sposobe delivery idempotentne (hold na karte dva krat aplikovat nechces), ale spravy o tom istom holde im kafka moze viac krat dorucit. Ine sposoby delivery pridali az neskor a maju performance impact, lebo informaciu o delivery musis sirit cez viacero nodov.
000001010006354000063542000637470901863309018872090190690901909209019167
DreeStyler
16.11.2022 - 17:32:06
, level: 3,
UP
NEW
Re[3]: kanon na vrabce ?
Noo, je to jedna z vlastnosti idempotencie, ze jednu spravu doruci iba raz. Vyrok dole uznas zapravdivy:
ze rovnaky vstup da vzdy rovnaky vystup(idempotencia)
https://cs.wikipedia.org/wiki/Idempotence
Viem, ze nizsie verzie Kafku idempotenciu nezarucovali. S vyssimi verziami to bola ziadana vlastnost a nevyhnutnost a podarilo sa im to zarucit vo verzii asi > 2.3 za cenu znizenia rychlosti. Teraz je to default, ktory sa da vypnut.