Distribuirani intervjui, 12 pitanja o distribuiranim sistemima (8.000 reči, 25 ručno crtanih crteža), obavezno čitanje za preokret intervjua

Sanfen O5611 reči19 minuta

8.800 reči, 25 ručno crtanih crteža, detaljno objašnjeno 12 čestih pitanja o distribuiranim sistemima na intervjuima (nema teških definicija za učenje), kada kandidati nauče ova pitanja, sigurno će pregaziti intervjuera, mislim da je sigurno (ručni pas). Organizovao: Chenmo Wang Er, klikni link za preuzimanje, autor: Sanfen O, klikni link za original.

Teorija distribuiranih sistema

1. Objasni CAP princip?

CAP je veoma važan teorem u dizajnu distribuiranih sistema, ukazuje na to da distribuirani sistemi ne mogu istovremeno da zadovolje konzistentnost (Consistency), dostupnost (Availability) i particionu toleranciju (Partition tolerance), najviše mogu istovremeno da zadovole dve od tri osobine.

Konzistentnost znači da svi čvorovi u isto vreme vide iste podatke. Na primer, ako ažuriram stanje korisničkog računa na serveru u Pekingu, onda server u Šangaju takođe treba odmah da vidi ovu izmenu. Konzistentnost zahteva da nakon što se ažuriranje podataka završi, sve naredne operacije čitanja moraju vratiti ažurirane vrednosti.

Dostupnost znači da sistem vraća razumne odgovore u normalnom vremenu odziva, čak i kada se deo čvorova pokvari. Na primer, e-trgovina ne sme biti potpuno nedostupna samo zato što se jedan čvor baze podataka srušio, korisnici moraju moći da vide informacije o proizvodima, možda je samo funkcionalnost naručivanja privremeno nedostupna.

Particiona tolerancija znači da sistem može da nastavi sa radom kada dođo do mrežne partitione. Mrežna particiona je neizbežan problem u distribuiranim sistemima, na primer prekid mreže između data centara, tada čvorovi u različitim data centrima ne mogu normalno da komuniciraju.

Pričaj o tvom razumevanju konačne konzistentnosti i jake konzistentnosti

Jaka konzistentnost zahteva da svi čvorovi u svakom trenutku vide potpuno iste podatke. To znači da čim se podatak uspešno upiše, sve operacije čitanja u sistemu moraju odmah da mogu da pročitaju najnoviju vrednost.

Kao kod bankarskog prenosa, novac se mora odmah dodati na nalog B u istom trenutku kada se skida sa naloga A, ne sme postojati intermedijarno stanje.

To znači, kada su u pitanju finansijski proračuni, mora se garantovati jaka konzistentnost. Na primer, korisnička dopuna, nakon uspešne naplate mora se odmah odraziti na stanju korisničkog računa, i svi servisni čvorovi moraju videti najnovije stanje.

Cena jake konzistentnosti je prilično visoka. Da bi se garantovala sinhronizacija podataka svih čvorova, sistem mora prilikom operacije pisanja da sačeka da svi relevantni čvorovi potvrde ažuriranje, što dovodi do većeg kašnjenja. I tokom mrežne partitione ili kvara čvora, sistem može odabrati da pauzira usluge da bi očuvao konzistentnost, dostupnost će biti ugrožena.

Konačna konzistentnost je relativno opuštenija, dozvoljava sistemu da u kratkom vremenu postoji nekonzistentnost podataka, ali garantuje da nakon određenog vremena, podaci svih čvorova će konačno dostići konzistentno stanje.

Tipična primena konačne konzistentnosti su distribuirani keš sistemi. Na primer, u Redis klasteru, nakon što glavni čvor uspešno upiše, odmah vraća odgovor, zatim asinhrono kopira na podređene čvorove. U ovom režimu, operacije čitanja mogu pročitati malo starije podatke, ali ukupna performansa i dostupnost sistema su odlične.

Vodič za Java intervju (plaćeni) sadrži originalno pitanje tehničkog intervjuja kolege iz NetEase-a 4 Cloud Music backend: predstavi CAP teoriju, pričaj o tvom razumevanju konačne konzistentnosti i jake konzistentnosti

memo: 23. septembra 2025. izmenjeno do ovde, danas sam pomagao prijatelju da izmeni CV, primio sam povratne informacije jednog prijatelja da mu je vrlo korisna Ergeova platforma za programiranje, dao mu je priliku da ovde uči tutorijale, projekte, i da komunicira sa mnogim prijateljima, što mu je vrlo pomoglo u razvoju. Ovakva pozitivna povratna informacija mi zaista mnogo znači, hvala.

2. Zašto CAP ne može biti istovremeno ostvaren?

Prvo, za distribuirane sisteme, particiona je neizostavna, tzv. particiona se odnosi na situaciju da distribuirani sistem može imati prekid mrežne veze u pojedinim oblastima, čime postaju izolovane oblasti.

Tada particiona tolerancija (P) mora biti zadovoljena, jer ako se žrtvuje particiona tolerancija, mora se staviti servis i resursi na jednu mašinu, ili jedan "živi i umiru zajedno" klaster, što je u suprotnosti sa ciljem distribuiranog sistema.

Tada na osnovu zadovoljene partcione tolerancije, da li može istovremeno da se zadovolji konzistentnost i dostupnost?

Pretpostavimo da sada imamo dve particiona N1 i N2, N1 i N2 imaju respektivno različite particione memorije D1 i D2, i različite servise S1 i S2.

Kod zadovoljene konzistentnosti, podaci N1 i N2 moraju biti isti, D1=D2.
Kod zadovoljene dostupnosti, bez obzira da li se pristupa N1 ili N2, može se dobiti pravovremeni odgovor.

Pretpostavimo ovakav scenario:

Korisnik je pristupio N1, izmenio podatke D1.
Korisnik je ponovo pristupio, zahtev je pao na N2. U ovom trenutku podaci D1 i D2 nisu konzistentni.

Nadalje:

Garantovati konzistentnost: u ovom trenutku podaci D1 i D2 nisu konzistentni, da bi se garantovala konzistentnost ne može se vratiti nekonzistentan podatak, dostupnost se ne može garantovati.
Garantovati dostupnost: odmah reagovati, dostupnost je garantovana, ali u ovom trenutku odgovoreni podaci nisu konzistentni sa D1, konzistentnost se ne može garantovati.

Dakle, može se videti, pod uslovom partcione tolerancije, konzistentnost i dostupnost su konfliktni.

3. Modeli i aplikacije odgovarajući CAP-u?

CA bez P

Teorijski napuštanje P (particiona tolerancija), tada C (jaka konzistentnost) i A (dostupnost) mogu se garantovati. U stvarnosti, particiona je neizbežna, strogo govoreći CA se odnosi na dozvolu particione da svaki podsistem i dalje održava CA.

Uobičajene primene CA modela:

Klaster baza podataka
xFS datotečni sistem

CP bez A

Napuštanje A (dostupnost), ekvivalentno tome da svaki zahtev mora biti strogo konzistentan između servera, a P (particiona) će uzrokovati beskonačno produženje vremena sinhronizacije, tako da i CP može biti garantovan. Mnoge tradicionalne distribuirane transakcije baza podataka pripadaju ovom režimu.

Uobičajene primene CP modela:

Distribuirane baze podataka
Distribuirani ključevi

AP bez C

Za visoku dostupnost i dozvolu particiona, mora se napustiti konzistentnost. Čim se particiona desi, čvorovi mogu izgubiti vezu, za visoku dostupnost svaki čvor može koristiti lokalne podatke za pružanje usluge, što će dovesti do globalne nekonzistentnosti podataka. Mnogi današnji NoSQL sistemi pripadaju ovoj kategoriji.

Uobičajene primene AP modela:

Web keš
DNS

Uzmimo jedan poznatiji primer, kao što su poznati registro centri ZooKeeper, Eureka, Nacos:

ZooKeeper garantuje CP
Eureka garantuje AP
Nacos ne samo podržava CP već i AP

4. Da li znaš BASE teoriju?

BASE (Basically Available, Soft state, Eventual consistency) je evoluirala postepeno iz CAP teorije, glavna ideja je da čak i ako se ne može postići jaka konzistentnost (Strong consistency), može se prema karakteristikama aplikacije primeniti odgovarajući način da se postigne efekat konačne konzistentnosti (Eventual consistency).

Glavno značenje BASE:

Basically Available (Osnovna dostupnost)

Šta je osnovna dostupnost? Pretpostavimo da se u sistemu pojavi nepredvidiv kvar, ali i dalje može raditi, samo u poređenju sa normalnim sistemom, može imati gubitak vremena odziva, ili degradaciju funkcionalnosti.

Soft State (Meko stanje)

Šta je tvrdo stanje? Zahteva da su kopije podataka više čvorova konzistentne, ovo je "tvrdo stanje".

Meko stanje se takođe zove slabo stanje, u poređenju sa tvrdim stanjem, dozvoljava da podaci u sistemu postoje u intermedijarnom stanju, i smatra da ovo stanje ne utiče na ukupnu dostupnost sistema, tj. dozvoljava da postoji kašnjenje podataka između kopija podataka više različitih čvorova.

Eventually Consistent (Konačna konzistentnost)

Gore smo rekli meko stanje, ali ne sme uvek biti meko stanje. Nakon određenog vremena, treba dostići konačno stanje, garantovati da sve kopije održavaju konzistentnost podataka, čime se postiže konačna konzistentnost podataka. Ovo vreme zavisi od mrežnog kašnjenja, opterećenja sistema, rešenja dizajna kopiranja podataka i drugih faktora.

Distribuirani ključevi

U vreme jednostavnih sistema, moglo se direktno koristiti lokalno zaključavanje za implementaciju zaključavanja konkurentnih resursa, u distribuiranoj okolini se moraju koristiti distribuirani ključevi.

5. Koja su rešenja za implementaciju distribuiranih ključeva?

Uobičajena rešenja za implementaciju distribuiranih ključeva su tri vrsta: MySQL distribuirani ključ, ZooKeeper distribuirani ključ, Redis distribuirani ključ.

5.1 Kako se implementira MySQL distribuirani ključ?

Implementacija distribuiranog ključa pomoću baze podataka je prilično jednostavna, kreira se tabela ključeva, baza podataka vrši ograničenje jedinstvenosti na poljima.

Zaključavanje se vrši dodavanjem jedne stavke u tabelu ključeva; otpuštanje ključa se vrši brisanjem stavke.

Ako se istovremeno podnesu konkurentni zahtevi bazi podataka, baza podataka će garantovati da samo jedan zahtev može dobiti ključ.

Ovo pripada operaciji IO baze podataka, efikasnost nije visoka, a česte operacije će povećati opterećenje baze podataka, stoga se ovaj način ne koristi često u scenarijima visoke konkurentnosti i visokih performansi.

5.2 Kako ZooKeeper implementira distribuirani ključ?

ZooKeeper je takođe uobičajen metod implementacije distribuiranog ključa.

Podaci ZooKeeper-a su slični direktorijumu fajlova, na primer postoji čvor lock, kreiranje podređenih čvorova pod ovim čvorom može garantovati redosled, čak i ako dva procesa istovremeno apliciraju za kreiranje novog čvora, takođe će kreirati dva čvora po redosledu.

Dakle možemo koristiti ovu karakteristiku za implementaciju distribuiranog ključa. Za određeni resurs kao direktorijum, zatim čvorovi ispod ovog direktorijuma su klijenti koje treba da dobiju ključ, svaki servis kreira čvor ispod direktorijuma, ako je broj njegovog čvora najmanji u direktorijumu, tada dobija ključ, inače čeka. Otpuštanje ključa je brisanje čvora koga je servis kreirao.

ZK je zapravo prilično teška distribuirana komponenta, stvarno nije toliko mnogo primena, pa implementacija distribuiranog ključa pomoću ZK-a zapravo nije toliko česta.

5.3 Kako Redis implementira distribuirani ključ?

Redis implementacija distribuiranog ključa je trenutno najšire primenjivani metod implementacije distribuiranog ključa.

Izvršavanje Redis komandi je jednonitno, Redis implementacija distribuiranog ključa koristi ovu karakteristiku.

Najašnija komanda za implementaciju distribuiranog ključa: setNx (set if not exist), ako ne postoji tada ažuriraj:

setNx resourceName value

Nakon zaključavanja, ako mašina padne, ovaj ključ ne može biti otpušten, stoga treba dodati vreme isteka, i vreme isteka mora biti atom operacija sa setNx, pre Redis 2.8 trebalo je koristiti lua skriptu, ali nakon redis 2.8 redis podržava nx i ex operaciju kao istu atom operaciju.

set resourceName value ex 5 nx

Redission

Naravno, uobičajeno u proizvodnji se koristi klijent Redission, vrlo dobro je enkapsulirao API distribuiranog ključa, i podržava RedLock.

Distribuirane transakcije

6. Šta su distribuirane transakcije?

U distribuiranoj okolini, uključuje više baza podataka, na primer baza plaćanja, baza proizvoda, baza narudžbina. Stoga je garantovanje konzistentnosti transakcija između servisa postalo vrlo komplikovano.

Sanfen O preokret intervjua: više baza podataka

Distribuirana transakcija je zapravo proširivanje koncepta transakcije jedne baze na više baza, cilj je garantovati konzistentnost podataka između servisa.

7. Koja su uobičajena rešenja za implementaciju distribuiranih transakcija?

Načini implementacije distribuiranih transakcija uglavnom uključuju:

Dvofazna potvrda (2PC): garantuje konzistentnost kroz faze pripreme i potvrde, ali su performanse lošije.
Trofazna potvrda (3PC): dodala mehanizam timeout na osnovu 2PC, smanjila blokiranje, ali i dalje postoji rizik od nekonzistentnosti podataka.
TCC: prema poslovnoj logici deli se na tri faze Try, Confirm i Cancel, pogodno za scenarije zaključavanja resursa.
Tabela lokalnih poruka: čuva događaje transakcije u bazi podataka, procesira poruke putem planiranih zadataka.
Distribuirane transakcije na osnovu MQ: realizuje asinhronu garantovanu putem reda poruka, koristi mehanizam ponovnog pokušaja za garantovanje konačne konzistentnosti, pogodno za scenarije sa nižim zahtevima za real-time.

7.1 Pričaj o 2PC dvofaznoj potvrdi?

Kada se govori o 2PC, mora se prvo reći za XA protokol u distribuiranim transakcijama.

U ovom protokolu, postoje tri uloge:

AP (Application): aplikacioni sistem (servis)
TM (Transaction Manager): menadžer transakcija (globalni menadžer transakcija)
RM (Resource Manager): menadžer resursa (baza podataka)

XA protokol koristi način dvofazne potvrde za upravljanje distribuiranim transakcijama. XA interfejs obezbeđuje standardni interfejs za komunikaciju između menadžera resursa i menadžera transakcija.

Način razmišljanja dvofazne potvrde može se sažeti: učesnici obaveštavaju koordinatora o uspehu ili neuspehu operacije, zatim koordinator na osnovu povratnih informacija svih učesnika odlučuje da li će svi učesnici potvrditi ili vratiti operaciju.

Faza pripreme: menadžer transakcija zahteva od svake baze podataka uključene u transakciju da predstavi (precommit) ovu operaciju, i da prijavi da li se može potvrditi
Faza potvrde: koordinator transakcije zahteva od svake baze podataka da potvrdi podatke, ili vrati podatke.

Prednosti: maksimalno garantuje jaku konzistentnost podataka, troškovi implementacije su niži, u svim glavnim mainstream bazama podataka postoji sopstvena implementacija, za MySQL je podržano od 5.5.

Mane:

Problem jednog čvora: menadžer transakcija igra veoma ključnu ulogu u celom procesu, ako se sruši, na primer ako je prva faza završena, u drugoj fazi se sprema da potvrdi i menadžer transakcija se sruši, menadžer resursa će zauvek blokirati, što dovodi do toga da baza podataka ne može da se koristi.
Sinhrono blokiranje: nakon što je priprema završena, resursi u menadžeru resursa su uvek u stanju blokiranja, dok se potvrda ne završi i ne oslobode resursi.
Nekonzistentnost podataka: mada je protokol dvofazne potvrde dizajniran za jaku konzistentnost distribuiranih podataka, i dalje postoji mogućnost nekonzistentnosti podataka, na primer u drugoj fazi, pretpostavimo da je koordinator poslao obaveštenje o potvrdi transakcije, ali zbog mrežnog problema ovo obaveštenje je primilo i izvršilo samo deo učesnika operacijom potvrde, ostali učesnici nisu primili obaveštenje i i dalje su u stanju blokiranja, u ovom trenutku se javlja nekonzistentnost podataka.

7.2 Da li znaš 3PC (trofaznu potvrdu)?

Trofazna potvrda (3PC) je poboljšana verzija dvofazne potvrde (2PC), rešava problem single-point kvara i sinhronog blokiranja protokola dvofazne potvrde.

Trofazna potvrda ima tri faze: CanCommit, PreCommit, DoCommit.

CanCommit: faza pripreme. Koordinator šalje učesnicima zahtev commit, ako učesnik može da potvrdi vraća Yes odgovor, inače vraća No odgovor.
PreCommit: faza predpotvrde. Koordinator na osnovu odgovora učesnika u fazi pripreme odlučuje da li će izvršiti transakciju ili prekinuti transakciju, učesnici nakon izvršene operacije vraćaju ACK odgovor, i istovremeno počinju da čekaju konačnu naredbu.
DoCommit: faza potvrde. Koordinator na osnovu odgovora učesnika u fazi pripreme odlučuje da li će izvršiti transakciju ili prekinuti transakciju:
Ako svi učesnici vrate ispravan ACK odgovor, tada potvrdi transakciju
Ako jedan ili više učesnika primi pogrešan ACK odgovor ili istekne vreme, tada prekida transakciju
Ako učesnik ne može pravovremeno da primi zahtev za potvrdu ili prekid transakcije od koordinatora, nakon isteka vremena čekanja, nastaviće da potvrdi transakciju

Može se videti da trofazna potvrda rešava samo problem single-point kvara i sinhronog blokiranja u dvofaznoj potvrdi, jer je dodat mehanizam timeout, ovaj mehanizam timeout deluje u fazi predpotvrde i fazi potvrde. Ako se čeka zahtev predpotvrde timeout, učesnik se direktno vraća pre faze pripreme. Ako se čeka zahtev potvrde timeout, učesnik će potvrditi transakciju.

Bilo da je 2PC ili 3PC ne može garantovati 100% konzistentnost podataka u distribuiranom sistemu.

7.3 Da li znaš TCC?

TCC (Try Confirm Cancel), je varijanta dvofazne potvrde, za svaku operaciju mora postojati odgovarajuća operacija potvrde i otkaza, kada operacija uspe poziva se operacija potvrde, kada operacija ne uspe poziva se operacija otkaza, slično dvofaznoj potvrdi, samo što je ovde potvrda i povratak usmerene na poslovni nivo, stoga se distribuirane transakcije implementirane na osnovu TCC-a mogu smatrati mehanizmom kompenzacije poslovnog nivoa.

Try: pokušaj posao koji treba izvršiti. Sistem narudžbina postavlja status trenutne narudžbine na plaćanje u toku, sistem zaliha proverava da li je trenutna preostala količina zaliha veća od 1, zatim postavlja količinu dostupne zalihe na količinu preostale zalihe-1.
Confirm: potvrdi izvršenje posla, ako se faza Try uspešno izvrši, nastavlja se faza Confirm, status narudžbine se menja na plaćanje uspešno, preostala količina zaliha se menja u količinu dostupne zalihe.
Cancel: otkaži posao koji treba izvršiti, ako se faza Try ne uspešno izvrši, izvršava se faza Cancel, status narudžbine se menja na neuspešno plaćanje, količina dostupne zalihe se menja u količinu preostale zalihe.

TCC je distribuirana transakcija na nivou poslovanja, garantuje konačnu konzistentnost, ne drži zauvek zaključane resurse.

Prednosti: prenosi dvofaznu potvrdu nivoa baze podataka na nivo aplikacije za implementaciju, izbjegava problem niskih performansi 2PC baze podataka
Mane: funkcije Try, Confirm i Cancel TCC-a mora obezbediti poslovna logika, troškovi razvoja su visoki. TCC ima veliki uticaj na poslovanje i čvrsto je povezan sa poslovom, potrebno je dizajnirati odgovarajuće operacije prema specifičnim scenarijima i poslovnoj logici

7.4 Da li znaš tabelu lokalnih poruka?

Osnovna ideja tabele lokalnih poruka je deljenje distribuirane transakcije na lokalne transakcije za procesiranje.

Na primer, može se dodati nova tabela poruka u bazu narudžbina, dodavanje nove narudžbine i nove poruke stavlja se u jednu transakciju za dovršetak, zatim putem rotacije se proverava tabela poruka, poruka se šalje u MQ, servis zaliha konzumira MQ.

Proces izvršavanja:

Servis narudžbina, dodaje jednu narudžbinu i jednu poruku, potvrđuje u jednoj transakciji
Servis narudžbina, koristi planirani zadatak za rotaciono pretraživanje tabele poruka sa statusom nesinhronizovanog, šalje u MQ, ako slanje ne uspe, ponavlja slanje
Servis zaliha, prima MQ poruku, menja tabelu zaliha, mora garantovati idempotentne operacije
Ako se izmena uspešno završi, poziva rpc interfejs za menjanje statusa tabele poruka sistema narudžbina na završeno ili direktno briše ovu poruku
Ako izmena ne uspe, može se ne procesirati, čekati ponovni pokušaj

Poruka u sistemu narudžbina može usled poslovnog problema biti ponavljano slana, stoga da bi se izbegla ova situacija može se zabeležiti broj slanja, kada se dostigne ograničenje broja slalja, alarma se javlja, ljudi se uključuju u procesiranje; servis zaliha mora garantovati idempotentnost, izbjegavati da ista poruka bude više puta konzumirana što dovodi do nekonzistentnosti podataka.

Ovo rešenje tabele lokalnih poruka ostvaruje konačnu konzistentnost, potrebno je dodati tabelu poruka u poslovni sistem, u poslovnoj logici postoji još jedna DB operacija umetanja, stoga će performanse imati gubitak, i interval konačne konzistentnosti uglavnom odlučuje interval vremena planiranog zadatka

7.5 Da li znaš MQ transakcije poruka?

Distribuirane transakcije na osnovu MQ znače asinhronu dekopliranje dve transakcije putem reda poruka, koristi mehanizam ponovnog pokušaja za garantovanje konačne konzistentnosti, pogodno za scenarije sa nižim zahtevima za real-time.

Servis narudžbina izvršava sopstvenu lokalnu transakciju i šalje poruku u MQ, servis zaliha prima poruku i izvršava sopstvenu lokalnu transakciju, ako konzumacija ne uspe, može koristiti mehanizam ponovnog pokušaja da garantuje konačnu konzistentnost.

Sanfen O preokret intervjua: distribuirane transakcije na osnovu MQ

Odloženi red u distribuiranim transakcijama se obično koristi za asinhronu kompenzaciju, planiranu verifikaciju i ponovni pokušaj kvara, osigurava konačnu konzistentnost podataka.

Kada se glavna transakcija završi, odloženi red će nakon određenog vremena proveriti status svih potransakcija, ako postoje neuspešne potransakcije, može pokrenuti operaciju kompenzacije, ponovni pokušaj ili povratak transakcije.

Kada distribuirani ključ iz određenog razloga nije normalno otpušten, može se kroz odloženi red nakon isteka vremena automatski otpustiti ključ, sprečava deadlock.

7.6 Da li znaš maksimalno napredovanje obaveštenja?

Maksimalno napredovanje obaveštenja je implementirano prilično jednostavnije, pogodno za neke poslove sa nižim zahtevima za real-time konačne konzistentnosti, na primer obaveštenje plaćanja, SMS obaveštenje.

Uzmimo obaveštenje plaćanja kao primer, poslovni sistem poziva platformu plaćanja za plaćanje, platforma plaćanja vrši plaćanje, nakon operacije plaćanja platforma plaćanja će sinhrono obavestiti poslovni sistem da li je operacija plaćanja uspešna, ako ne uspe,će stalno asinhrono ponavljati, ali postoji maksimalan broj obaveštenja, ako se nakon ovog broja obaveštenja i dalje ne uspešno obavesti, više neće obaveštivati, poslovni sistem sam poziva query interfejs koji platforma plaćanja pruža, za poslovni sistem da proveri da li je operacija plaćanja uspešna.

Proces izvršavanja:

Poslovni sistem poziva interfejs plaćanja platforme plaćanja, i lokalno beleži, status plaćanja je plaćanje u toku
Nakon što platforma plaćanja izvrši operaciju plaćanja, bilo uspešno ili neuspešno, sinhrono daje poslovnom sistemu obaveštenje o rezultatu
Ako obaveštenje stalno ne uspe, prema pravilima ponovnog pokušaja asinhrono ponavlja, nakon dostizanja maksimalnog broja obaveštenja, više ne obaveštava
Platforma plaćanja pruža query interfejs rezultata operacije plaćanja narudžbine
Poslovni sistem prema određenim poslovnim pravilima query platformu plaćanja za rezultat plaćanja

8. Šta vi koristite? Možeš li pričati o Seata-i?

Mi koristimo prilično često Seata - sama implementacija distribuirane transakcije je prilično problematična.

Seata ima za cilj da ne utiče na poslovani nivo, stoga polazi od dvofazne potvrde bez uticaja na poslovani nivo (globalna transakcija), poboljšava se na osnovu tradicionalne dvofazne potvrde, distribuiranu transakciju razume kao globalnu transakciju koja sadrži nekoliko granantransakcija. Dužnost globalne transakcije je koordinisati grane transakcija koje upravlja da postignu konzistentnost, ili sve zajedno uspešno potvrde, ili sve zajedno neuspešno vraćaju. To je svi uspešni ili svi neuspešni~

U Seata-i postoje nekoliko važnih uloga:

TC (Transaction Coordinator): koordinator transakcija. Upravlja statusom svih granatransakcija, koristi se za globalnu potvrdu i povratak transakcije.
TM (Transaction Manager): menadžer transakcija. Koristi se za pokretanje, potvrdu ili povratak transakcije.
RM (Resource Manager): menadžer resursa. Koristi se za upravljanje resursima na nivou granatransakcije, prijavljuje se TC-u za granatransakciju, prijavljuje status granatransakcije, prima komande TC-a za potvrdu ili povratak granatransakcije.

Ceo proces izvršavanja Seata-e:

TM u servisu A se prijavljuje TC-u za pokretanje globalne transakcije, TC kreira globalnu transakciju i vraća jedinstveni XID
RM u servisu A se prijavljuje TC-u za granatransakciju, zatim ovu granatransakciju stavlja pod nadležnost globalne transakcije koja odgovara XID-u
Servis A počinje da izvršava granatransakciju
Servis A počinje remote call servisa B, u ovom trenutku XID se širi prema lancu poziva
RM u servisu B se takođe prijavljuje TC-u za granatransakciju, zatim ovu granatransakciju stavlja pod nadležnost globalne transakcije koja odgovara XID-u
Servis B počinje da izvršava granatransakciju
Nakon završetka poziva globalne transakcije, TM će na osnovu anomalije da se TC-u prijavi potvrda ili povratak globalne transakcije
TC koordinira sve granatransakcije pod svojom nadležnošću, odlučuje da li će potvrditi ili vratiti

Vodič za Java intervju (plaćeni) sadrži originalno pitanje tehničkog intervjuja kolege iz ByteDance-a 17 backend: kako implementirati distribuirane transakcije zašto koristiti odloženi red

Algoritmi distribuirane konzistentnosti

9. Da liznaš distribuirani algoritam paxos?

Paxos je malo sličan ranije pomenutom 2PC, 3PC, ali je više potpun od ovih dva algoritma. Dobio je inženjersku primenu u mnogim velikim kompanijama, na primer Alijeva OceanBase distribuirana baza podataka, Google-ov chubby distribuirani ključ.

Šta je Paxos algoritam?

Paxos algoritam je algoritam konzistentnosti na osnovu poruka i sa efikasnom karakteristikom tolerancije kvara, trenutno je priznat kao jedan od najefikasnijih algoritama za rešavanje problema distribuirane konzistentnosti.

Kako radi Paxos algoritam?

Uloge

U Paxos-u postoje nekoliko uloga:

Proposer (Predlagač): predlagač predlaže predlog, koristi se za glasanje.
Accecptor (Prihvatač): glasa za predlog, i prihvata postignute konsenzus predloge.
Learner (Učenik): obavešten je o rezultatu glasanja, prihvata postignute konsenzus predloge.

U praksi, jedan čvor može istovremeno obavljati različite uloge.

Predlagač predlaže predlog, predlog=broj+vrednost, može se predstaviti kao [M,V], svaki predlog ima jedinstven broj, i trend rasta broja je povećanje.

Proces algoritma

Paxos algoritam sadrži dve faze, prva faza Prepare (priprema), druga faza Accept (prihvatanje).

Faza Prepare (priprema)

Predlagač predlaže novi predlog P[Mn,?], zatim šalje zahtev pripreme sa brojem Mn nekom podskupu članova prihvatača koji je veći od polovine
Ako prihvatač primi zahtev pripreme sa brojem Mn, i broj Mn je veći od svih brojeva zahteva pripreme na koje je već reagirao, tada će vratiti predlog sa najvećim brojem koji je već odobrio kao odgovor predlagaču, u isto vreme ovaj prihvatač će obećati da neće odobriti predlog sa brojem manjim od Mn

Sažeto, prihvatač nakon prijema predloga daje predlagaču dva obećanja i jedan odgovor:

Dva obećanja:
Obećava se da neće prihvatati Prepare zahtev sa brojem predloga manjim ili jednakim Mn
Obećava se da neće prihvatati Accept zahtev sa brojem predloga manjim od Mn
Jedan odgovor:
Pod uslovom da ne krši prethodna obećanja, vraća vrednost i broj predloga Mmax postavljen od najvećeg broja predloga u prošlim predlogima, ako ovu vrednost nikada nije postavio nijedan predlog, vraća prazno. Ako ne zadovoljava prethodna obećanja, tj. primljeni broj predloga nije najveći koji je čvor odlučivanja primio, tada se može direktno ignorisati ovaj zahtev za pripremu.

Faza Accept (prihvatanje)

Ako predlagač primi odgovor na zahtev pripreme sa brojem Mn od više od polovine prihvatača, tada će poslati zahtev prihvatanja za [Mn,Vn] prihvatačima, obratite pažnju da je Vn vrednost onog predloga sa najvećim brojem u primljenom odgovoru, ako odgovor ne sadrži nijedan predlog, tada može proizvoljno odabrati jednu vrednost.
Ako prihvatač primi ovaj zahtev prihvatanja za predlog [Mn,Vn], sve dok ovaj prihvatač još uvek nije reagirao na zahtev pripreme sa brojem većim od Mn, može proći ovaj predlog.

Kada predlagač primi odgovore prihvatanja većine prihvatača, pregovori se završavaju, formira se odluka konsenzusa, formiranu odluku šalje svim učeničkim čvorovima za učenje.

Dakle detaljni proces celokupnog Paxos algoritma je sledeći:

Koje su mane Paxos algoritma? Kako optimizovati?

Prethodni opis se može nazvati Basic Paxos algoritam, pod uslovom jednog predlagača nema problema, ali ako postoji više predlagača koji se ne žele povući, tada može dovesti do toga da ceo proces predlaganja uđe u beskonačnu petlju.

Lamport je predložio ideju algoritma Multi Paxos.

Ideja algoritma Multi Paxos, jednostavno rečeno, je da se uslovima više predlagača bira jedan Leader (vođa), vođa služi kao jedini predlagač, ovako se može rešiti problem konflikta predlagača.

10. Pričaj o Raft algoritmu?

Šta je Raft algoritam?

Raft je takođe jedan algoritam konzistentnosti, sa Paxos istim ciljem. Ali ima još jedan naziv - algoritam konzistentnosti lako razumljiv. Paxos i Raft su nastali da bi se ostvarila konzistentnost. Ovaj proces je kao izbor, kandidati moraju da ubede većinu glasača (Server) da glasaju za njega, jednom kada se izaberu prate njegove operacije. Razlika između Paxos i Raft je u konkretnom procesu izbora.

Kako radi Raft algoritam?

Uloge Raft algoritma

Raft protokol deli Server procese u tri uloge:

Leader (Vođa)
Follower (Pratilac)
Candidate (Kandidat)

Kao demokratsko društvo, vođu biraju pratioci glasanjem. Na početku nema vođe, svi učesnici u klasteru su pratioci.

Tada prvo započinje jedno velike izbore. U periodu velikih izbora svi pratioci mogu učestvovati u kampanji, u ovom trenutku uloge svih pratioca postaju kandidati, demokratskim glasanjem se bira vođa, zatim se završavaju izbori, svi kandidati osim vođe ponovo postaju pratioci i služe vođu.

Ovde se pominje jedan koncept «mandatni period», izraženo terminom Term.

Transicija uloga tri kategorije je sledeća:

Proces izbora vođe

Raft koristi heartbeat (otkritje srca) za pokretanje izbora vođe. Kada Server pokrene, inicijalizuje se kao Follower. Vođa periodično šalje heartbeat svim Follower-ima. Ako Follower ne primi heartbeat vođe u roku isteka izbora,će sačekati random vreme zatim pokrenuti izbor vođe.

Follower povećava trenutni term za jedan i konvertuje se u Candidate. Prvo glasa za sebe i šalje RequestVote RPC ostalim serverima u klasteru. Rezultat je jedan od tri situacije:

Dobio je većinu (preko 1/2) glasova, uspešno izabran za vođu;
Primio poruku vođe, pokazuje da je drugi server već ranije bio izabran za vođu;
Nijedan Server nije dobio većinu glasova, izbor vođe nije uspeo, čeka istek vremena izbora (Election Timeout) zatim pokreće sledeće izbore.

Nakon izbora vođe, vođa održava vladavinu periodičnim slanjem **heartbeat poruka svim pratilacima**. Ako pratilacodređeno vreme ne primiheartbeatvođe, tada smatra da se vođa` možda srušila, zatim ponovo pokreće proces izbora.

Distribuirani dizajn

11. Pričaj o tome šta je idempotentnost?

Šta je idempotentnost?

Idempotentnost je matematički koncept, kada se koristi na interfejsu: na interfejsu se može razumeti kao: isti interfejs, više puta šalji isti zahtev, rezultat zahteva je konzistentan.

Jednostavno rečeno, više poziva je jedan poziv.

Šta je problem idempotentnosti?

U radu sistema, može se pojaviti ovakav problem:

Korisnik prilikom popunjavanja određenog form obrazca, gremo je brzo kliknuo dva puta dugme za čuvanje, u tabeli se stvarno pojavila dva duplirata podataka, samo id je drugačiji.
Razvojni inženjeri u projektu kako bi rešili problem timeout-a interfejsa, obično uvode mehanizam ponovnog pokušaja. Prvi put kada se zahtev za interfejs istekne, zatraživaoca nije pravovremeno dobio rezultat (u ovom trenutku je možda već bio uspešan), tada će ovaj zahtev ponoviti nekoliko puta, ovo takođe može stvoriti duplirane podatke.
mq potrošač prilikom čitanja poruka, ponekad može pročitati duplirane poruke, takođe može stvoriti duplirane podatke.

Ovo su uobičajeni problemi idempotentnosti.

U distribuiranom sistemu, sve dok donji servis ima operacije pisanja (čuvanje, ažuriranje), može se pojaviti problem idempotentnosti.

PS: idempotentnost i sprečavanje duplikata su malo drugačije, sprečavanje duplikata naglašava sprečavanje dupliranja podataka, idempotentnost naglašava više poziva kao jedan, sprečavanje duplikata uključuje idempotentnost.

Kako garantovati idempotentnost interfejsa?

select pre insert

U interfejsu čuvanja podataka, pre insert, prvo prema polju requestId uradi select podataka. Ako podatak već postoji, direktno vrati, ako ne postoji, tek izvrši insert operaciju.

dodaj jedinstveni indeks

Dodavanje jedinstvenog indeksa je vrlo jednostavan ali vrlo efikasan način, ako se duplirani podaci ubace, bacaće se izuzetak, za garantovanje idempotentnosti obično treba uhvatiti ovaj izuzetak.

Ako je java program treba uhvatiti: DuplicateKeyException izuzetak, ako se koristi spring framework treba uhvatiti i: MySQLIntegrityConstraintViolationException izuzetak.

dodaj pesimistično zaključavanje

Logika ažuriranja, na primer ažuriranje stanja korisničkog računa, može se dodati pesimistično zaključavanje, zaključa odgovarajući red podatka korisnika. U istom trenutku samo jedan zahtev može dobiti ključ, ostali zahtevi čekaju.

select * from user id=123 for update;

Ovaj način ima jednu manu, zahtev koji ne dobije ključ obično može samo prijaviti neuspeh, teško je garantovati da interfejs vraća istu vrednost.

dodaj optimistično zaključavanje

Logika ažuriranja, takođe može koristiti optimističko zaključavanje, performanse su bolje. Može se dodati polje timestamp ili version u tabelu, na primer version:

Pre ažuriranja, prvo upit podatke, version takođe koristi kao uslov ažuriranja, istovremeno ažurira i version:

update user set amount=amount+100,version=version+1 where id=123 and version=1;

Nakon uspešnog ažuriranja, version raste, ponovljeni zahtev za ažuriranje neće moći da ažurira.

napravi tabelu sprečavanja duplikata

Ponekad u tabeli nisu svi scenariji gde se ne dozvoljava stvaranje dupliranih podataka, samo određeni specifični scenariji se ne dozvoljavaju. U ovaj čas, može se koristiti način tabele sprečavanja duplikata.

Na primer u konzumaciji poruka, kreira se tabela sprečavanja duplikata, čuva jedinstveni ID poruke, prilikom konzumacije prvo proveri da li je već konzumirano, već konzumirano direktno vrati uspeh.

state mašina

Neki poslovni tabele imaju stanja, na primer tabela narudžbina ima: 1-narudžbina, 2-plaćeno, 3-završeno, 4-opozvano i druga stanja, može se postići idempotentnost ograničavanjem toka stanja.

distribuirani ključ

Direktno dodavanje ključa na bazu podataka nije prijateljsko po performansama, može se koristiti način distribuiranog ključa, trenutno najpopularnija implementacija distribuiranog ključa je kroz Redis, konkretna implementacija obično koristi Redission framework.

token mehanizam

Pre poziva interfejsa, treba prvo dobiti jedinstveni token, zatim sa ovim tokenom otići da se obavi poslovna operacija, server na osnovu toga da li ovaj token postoji, odlučuje da li je to duplirani zahtev.

Distribuirano ograničavanje protoka

12. Koji algoritmi ograničavanja protoka znaš?

Brojač

Brojač je prilično grub i jednostavan, na primer ako želimo da ograničimo koliko zahteva može proći u 1s, ideja implementacije je počevši od prvog zahteva početi da merimo vreme, u narednih 1s, svaki zahtev broj se povećava za 1, zahtevi koji premašuju maksimalni broj zahteva će biti odbijeni, nakon isteka 1s brojanje se resetira na nulu, ponovo počinje brojanje.

Ovaj način ima veliku manu: na primer u prvih 10ms je već prošao maksimalni broj zahteva, tada zahtevi u narednih 990ms mogu biti samo odbijeni, ovakva pojava se zove "fenomen šiljka".

Algoritam curenog bureta

Dno bureta izvodi vodu konstantnom brzinom, brzina ulivanja vode može biti brza ili spora, ali kada je količina ulivene vode veća od količine izlivene vode, voda će biti smeštena u buretu, neće se direktno baciti; ali buret takođe ima ograničenje kapaciteta, kada se buret napuni vodom, prelivena deoba će i dalje biti bačena.

Implementacija algoritma: može se pripremiti jedan red za čuvanje zahteva koji se privremeno ne mogu procesirati, zatim kroz pool niti periodično dobavlja zahteve iz reda za izvršavanje.

Algoritam token bureta

Token burret je mesto koje proizvodi tokene pristupa, brzina proizvodnje je konstantna, kada korisnik pristupa ako u buretu ima token može pristupiti, inače će okidati ograničavanje protoka.

Rešenje implementacije: Guava RateLimiter ograničavanje protoka

Guava RateLimiter je ograničavanje protoka koje je pružio Google, zasnovano na algoritmu token bureta, prilično pogodno za sisteme jedne instance.

Ovaj broj distribuiranih intervjua je ovde organizovan, uglavnom su teorijska pitanja, distribuirani je zapravo vrlo velika kategorija, na primer distribuirani pozivi, distribuirano upravljanje...

Dakle, ovaj članak je samo početak, kasnije će biti članaka o temama distribuiranih poziva (RPC), mikroservisa, ostajte uz nas.

Detaljno objašnjeno 12 čestih pitanja distribuiranih intervjua, ovaj intervju sigurno će pregaziti intervjuera, organizovao: Chenmo Wang Er, klikni link za preuzimanje, autor: Sanfen O, klikni link za original.

Ništa me ne zadržava——osim cilja, čak i ako na obali ima ruža, ima hlad, ima mirne luke, ja sam brod bez veza.

Serijski sadržaj: