12 odabranih Redis intervju pitanja👍

Redis je na intervjuu prepreka koja se ne može zaobići — ako u biografiji napišete da ste koristili Redis, sigurno vas neće zaobići. Danas ćemo simulirati kako intervjuer na temu Redis-a korak po korak produbljuje pitanja, sveobuhvatno proveravajući koliko kandidat poznaje Redis.

Xiao Er: Zdravo, došao sam na intervju.

Intervjuer: Zdravo, Xiao Er. Pročitao sam tvoju biografiju — dobro poznaješ Redis, pa ću ti postaviti nekoliko pitanja vezanih za Redis. Prvo pitanje: da li je Redis jednoprocesni ili višeprocesni (single-threaded ili multi-threaded)?

Xiao Er:

Različite verzije Redis-a koriste različite modele niti. Pre verzije Redis 4.0 koristio se model jedne niti; posle verzije 4.0 dodata je podrška za više niti.

Pre 4.0, iako kažemo da je Redis jednoprocesni, to se odnosi samo na to da mrežna IO nit i Set i Get operacije obavlja jedna nit. Ali Redis-ova persistencija i sinhronizacija klastera i dalje se obavljaju u drugim nitima.

Posle 4.0 dodata je podrška za više niti, koja se prvenstveno ogleda u asinhronom brisanju velikih podataka, na primer unlink key, flushdb async, flushall async itd.

Intervjuer: Odličan odgovor. Zašto je onda Redis pre 4.0 odabrao jednoprocesni model? A i pored toga bio je tako brz?

Xiao Er:

Mislim da je izbor jedne niti prvenstveno iz jednostavnosti korišćenja — nema konkurencije za brave, sve operacije mogu se obaviti bez brava, bez mrtvih blokada i bez overhead-a zbog preklapanja niti. Istovremeno, jednoprocesni model ne može u potpunosti da iskoristi performanse višjezgrenog CPU-a.

Što se tiče toga zašto je jednoprocesni model toliko brz, mislim da su glavni razlozi sledeći:

• Većina Redis operacija se obavlja u memoriji, gde je efikasnost izvršavanja sama po sebi veoma visoka, a koriste se i efikasne strukture podataka poput hash tabele i skip liste.
• Korišćenje jedne niti izbegava konkurenciju između niti, štedi vreme i performanse na context switch-evima, i ne pojavljuju se mrtve blokade.
• Koristi I/O multiplexing mehanizam za obradu velikog broja klijentskih Socket zahteva; pošto je to zasnovano na neblokirajućem I/O modelu, Redis može efikasno da obavlja mrežnu komunikaciju, a I/O read/write proces više ne blokira.

Intervjuer: Dobro. Kako onda Redis obezbeđuje da se podaci ne izgube?

Xiao Er:

Redis podaci se čuvaju u memoriji. Da bi se osiguralo da se podaci ne izgube, potrebno je prebaciti ih iz memorije na disk, kako bi se nakon restarta servera podaci mogli oporaviti sa diska — to je Redis-ova persistencija podataka. Redis persistencija ima tri načina.

1) AOF log (Append Only File): beleži sve komande operacija i dodaje ih u fajl u tekstualnom obliku.

2) RDB snapshot (Redis DataBase): podatke iz memorije u određenom trenutku upisuje na disk u binarnom obliku.

3) Hibridna persistencija: u Redis 4.0 dodata je hibridna persistencija koja objedinjuje prednosti RDB-a i AOF-a.

Intervjuer: Onda mi objasni princip implementacije AOF i RDB.

Xiao Er:

AOF koristi pristup write-after log-a — Redis prvo izvrši komandu i upiše podatke u memoriju, a zatim zapisuje log u fajl. AOF log beleži komande operacija, a ne stvarne podatke; ako se AOF koristi za oporavak nakon pada, potrebno je ponovo izvršiti sve komande iz loga.

RDB koristi pristup memorijskog snapshot-a — on beleži podatke u određenom trenutku, a ne operacije; zato pri oporavku nakon pada dovoljno je samo pročitati RDB fajl u memoriju, čime se ostvaruje brz oporavak.

Intervjuer: Malopre si pomenuo da AOF koristi „write-after log" pristup, dok MySQL koji inače koristimo primenjuje „write-ahead log". Zašto Redis prvo izvršava komandu, a zatim upisuje podatke u log?

Xiao Er: To je prvenstveno zato što Redis pre upisivanja u log ne vrši proveru sintakse komande, pa beleži samo uspešno izvršene komande, izbegavajući situaciju da se zapiše pogrešna komanda; osim toga, upisivanje loga nakon izvršenja komande ne blokira tekuću write operaciju.

Intervjuer: A koje su rizici naknadnog upisivanja loga?

Xiao Er: Ja... ovo ne znam.

Intervjuer:

U redu, naknadno upisivanje loga nosi dva glavna rizika:

• Podaci mogu biti izgubljeni: ako Redis upravo izvrši komandu, a zatim dođe do pada servera, ta komanda može biti izgubljena.
• Može blokirati druge operacije: AOF log se zapravo izvršava u glavnoj niti, tako da kada Redis upisuje log fajl na disk, i dalje blokira sledeće operacije.

Imam još jedno pitanje: da li RDB snapshot blokira nit?

Xiao Er: Redis pruža dve komande za generisanje RDB snapshot fajla — save i bgsave. save komanda se izvršava u glavnoj niti i izaziva blokadu. bgsave komanda kreira child proces za upis RDB fajla, čime se izbegava blokada glavne niti — to je i podrazumevana konfiguracija Redis RDB-a.

Intervjuer: Da li se podaci mogu menjati dok RDB radi snapshot?

Xiao Er: save je sinhron i blokira klijentske komande; tokom bgsave podaci se mogu menjati.

Intervjuer: Kako onda Redis rešava da dozvoli izmenu podataka dok bgsave radi snapshot?

Xiao Er: Ovaj... to ne znam...

Intervjuer:

Ovde se prvenstveno koristi child proces bgsave-a. Konkretne operacije su sledeće:

• Ako glavna nit izvršava read operaciju, glavna nit i bgsave child proces se međusobno ne ometaju.
• Ako glavna nit izvršava write operaciju, izmenjeni podaci se kopiraju u jednu kopiju, a zatim bgsave child proces tu kopiju upisuje u RDB fajl. Tokom tog procesa glavna nit i dalje može direktno menjati originalne podatke.

Treba napomenuti da je za Redis učestalost RDB izvršavanja veoma važna, jer utiče na potpunost snapshot podataka i stabilnost Redis-a. Zato je u Redis 4.0 dodata hibridna persistencija koja kombinuje AOF i RDB: podaci se u RDB formatu upisuju u fajl, a zatim se naknadne komande operacija čuvaju u AOF formatu u istom fajlu — čime se obezbeđuje brz restart Redis-a i smanjuje rizik od gubitka podataka.

Xiao Er: Naučio sam, naučio sam.

Intervjuer: Onda mi reci kako Redis postiže visoku dostupnost?

Xiao Er: Redis postiže visoku dostupnost na tri glavna načina: master-slave replikacija, Sentinel (sentinel) mod i Redis klaster.

1) Master-slave replikacija

Sa jednog prethodnog Redis servera, podaci se sinhronizuju na više Redis slave servera — model jedan master, više slave, slično principu MySQL master-slave replikacije.

2) Sentinel mod

Korišćenje Redis master-slave servisa nosi jedan problem — kada Redis master-slave serveri padnu, potrebno je ručno izvršiti oporavak. Da bi se rešio taj problem, Redis je uveo Sentinel mod (jer Sentinel mod može da nadgleda master-slave servere i pruži funkciju automatskog oporavka od katastrofe).

3) Redis Cluster (klaster)

Redis Cluster je distribuirani, decentralizovani režim rada, uveden u verziji Redis 3.0 kao rešenje za Redis klaster. On raspoređuje podatke na različite servere, čime se smanjuje zavisnost sistema od jednog master čvora i povećavaju performanse čitanja i pisanja Redis servisa.

Intervjuer: U Sentinel modu, podaci su zaštićeni replikama, a dostupnost se nadgleda pomoću Sentinela — kada master padne, bira se slave čvor za novi master, što već zadovoljava naše potrebe u produkciji. Zašto onda još uvek treba koristiti klaster mod?

Xiao Er: Sentinel mod je u suštini i dalje master-slave model. U master-slave modelu možemo povećanjem broja slave čvorova proširiti sposobnost čitanja, ali ne možemo proširiti sposobnost pisanja i skladištenja — kapacitet skladištenja je ograničen onim što master čvor može da podnese. Zato, da bismo proširili sposobnost pisanja i skladištenja, moramo uvesti klaster mod.

Intervjuer: U klasteru ima mnogo Master čvorova — kako Redis Cluster pri čuvanju podataka određuje koji čvor da izabere?

Xiao Er: Verovatno se koristi neki hash algoritam, ali ne znam tačno...

Intervjuer: U redu, to je sve za danas, idi kući i čekaj našu vest o intervjuu.

Xiao Er: U redu, hvala. Možeš li mi reći kako Redis Cluster implementira izbor čvora?

Intervjuer:

Redis Cluster koristi algoritam sličan consistent hashing-u za izbor čvora — šta je consistent hashing algoritam, pogledaj sam kad dođeš kući.

Redis Cluster se deli na 16384 Slot-ova (slotova). Hash slot je sličan particiji podataka — svaki par ključ-vrednost se na osnovu svog ključa mapira u jedan hash slot. Konkretan proces izvršavanja se sastoji od dva glavna koraka.

1. Na osnovu ključa para ključ-vrednost, izračunava se vrednost od 16 bita prema CRC16 algoritmu.

2. Zatim se ta 16-bitna vrednost deli modulom sa 16384, čime se dobija ostatak u opsegu 0~16383; svaki ostatak predstavlja jedan hash slot odgovarajućeg broja.

Svaki Redis čvor je odgovoran za obradu dela slotova. Ako imate tri master čvora A, B, C, čvorovi su zaduženi za sledeće slotove:

Čvor	Slotovi
A	0-5000
B	5001 - 10000
C	10001 - 16383

Na taj način se realizuje izbor čvora u klasteru.

---

Članak potiče iz JAVA Rizhilu, autor: Piaomiao Jam Link reprodukcije: https://mp.weixin.qq.com/s/GFUHslsSm96fJbhsCkFe_w