Pitanje scenarija: Kako dizajnirati rang listu?

Prijatelji koji vide ovu objavu moraju proći proljećnu regrutaciju/letnju praksu!!!

Tokom jesenje regrutacije sam više puta pitao za pitanja scenarija, u velikim i srednjim firmama frekvencija ispita je prilično visoka, obično se stavlja kao poslednje pitanje da bi se odugovlo vreme, sreo sam i situacije gde me odmah pitaju kako da dizajniram sistem (intervjuer time odlučuje o svom stavu prema tebi). Stoga sam rešio da otvorim ovu rubriku pitanja scenarija, podelim pitanja scenarija koja sam susreo tokom jesenje regrutacije i kako da odgovorim, zainteresovani prijatelji koji osećaju da je korisno dajte lajk i pratite me, vaši lajkovi i praćenje su najveća motivacija za moj kontinuirano ažuriranje!!!

Bez previše priče, krenimo na današnju temu, dizajn rang liste!!!

Rang lista je vrlo česta funkcija, koristi se u raznim scenarijima kao što su društvene mreže, igre itd., rang liste poena, lajkova, poklona, rezultata itd., ove rang liste su u suštini zasnovane na brojanju i sortiranju. Različiti scenariji imaju sitne razlike u dizajnu, ovde ću pričati samo o tome kako dizajnirati univerzalni sistem rang lista, za specifične scenarije napravite sitne prilagodbe, čak iako na intervjuu možete odgovoriti samo na univerzalni dizajn rang lista opisan u ovom tekstu, to je dovoljno, jer za diplomirane studente ispiti ići samo do ovog nivoa, na intervjuu treba što više odgovoriti na pitanja, teško je tražiti da se sva pitanja mogu odgovoriti...

Svi ste verovatno čitali neke "pamćene standardne odgovore", moći ćete direktno odgovoriti korišćenjem zset za rangiranje.

Ja sam takođe na intervjuu odgovarao: Koristiti poene svakog korisnika kao score elemenata u zset, korisnički ID kao vrednost elementa. Korišćenjem sort funkcije koju nudi zset, možete sortirati po broju poena od visokog ka niskom.

Tada me intervjuer pitao ako su bodovi isti, prema podrazumevanim pravilima sortiranja sortirano po vrednosti, on želi da se sortira po vremenskom redosledu, to jest kada su bodovi isti oni koji su ranije stigli na rang listu stoje ispred.

Tada me to zatvorilo, nakon intervjua sam našao rešenje:

Da bi se realizovalo da se pri istim bodovima sortira po vremenskom redosledu, score se može postaviti kao decimalni broj, gde je integer deo bodovi, decimalni deo vremenski pečat

To jest: score = bodovi + 1 - vremenski pečat/1e13

U ovom slučaju kada su bodovi isti, raniji vremenski pečat je manji, podeljen sa jako velikim brojem dobija se manji broj, oduzeto od 1 dobija se veća razlika, time se realizuje

Da se pri istim bodovima ranije stigli na rang listu stoje ispred.

Ali kasnije intervjuer želi da pričam o nekim idejama dizajna sistema, tada uopšte nemam ideje o dizajnu sistema, bez obzira kasnije nakon reanalize sam sumirao jednu metodologiju, ovde je delim sa svima.

(1) Očiti zahtevi projekta: ovde je dizajnirati sortiranje na osnovu podataka kao bodovi ili lajkovi itd. Istovremeno obratiti pažnju na količinu zahteva, da li je potrebno dizajnirati visoku konkurenciju/visoku dostupnost; uz to da li postoji zahtev za realno vremensko, gledja jaku konzistentnost ili konačnu konzistentnost

(2) Odrediti poslovnu logiku: nakon što novi korisnik stigne na rang listu rang lista se menja; nakon promene bodova korisnika prilagođava se rangiranje

(3) Dizajn arhitekture: skladište (MySQL/Redis) + servis (da li je potrebno podeliti na više servisa)

Uglavnom rang lista se sastoji od dva dela, struktura sortiranja i struktura agregacije informacija. To jeste ono što vidimo na rang listi prvih 100 po broju lajkova, a agregacija informacija je kada kliknemo na avatar korisnika možemo videti njegove detaljne informacije. U početku dizajna sistema, front-end sinhrono poziva sistem rang liste, za slučaj malog konkurentskog saobraćaja, može se direktno koristiti MySQL kao skladište, direktno operisati IO baze podataka, ovde je limit baze podataka 5000/s. Može se prvo uzeti sve podatke iz baze podataka u memoriju i sortirati (pod uslovom da količina podataka nije velika)

Ali kako konkurentnost i broj korisnika rastu, ovo jako zavisno sinhrono pozivanje će povećati kašnjenje interfejsa. Tada se može dodati slojevi sredine, to jest jedno od tri sekira za poboljšanje performansi interfejsa (keš, red poruka, podela baze podataka). Na primer korišćenje redova poruka kao Rocket MQ ili Kafka (MQ). Kada je saobraćaj velik može smanjiti vrhu peaks za sistem rang liste, takođe može batch insert u bazu podataka smanjiti IO broje, poboljšati efikasnost inserta. Međutim, nakon korišćenja MQ mora dobro obraditi idempotentnost (pitanje pamćenja standardnih odgovora, koje načine mogu realizovati idempotentnost poruka MQ). Kada saobraćaj i konkurentnost kontinuirano rastu, takmacenje read-write lockova baze podataka se pojačava, može se koristiti podela master-slave da se rasporedi pritisak čitanja, naravno može i direktno razmisliti o korišćenju Redis-a kao rang liste. Korišćenjem sortset tipa Redis-a za sortiranje (ovde treba savladati zset, i srodne pamćene standardne odgovore treba upoznati, mogu biti pitani), na primer za rangiranje broja komentara može se koristiti komanda ZINCRBY za ažuriranje, upit koristi ZREVRANGE da dobije prvih N rang i bodove. U arhitekturi Redis može biti potrošač, pretplati MQ poruke, prilikom konzumacije sprovesti idempotentnu proveru, koristiti Lua skriptu da garantuje atomičnost operacije. (ovaj pasus može biti korišćen kao klasična formulacija)

Zaključak:

Za rang listu, jednostavno može direktno koristiti Redis sortiranje, ali ako treba garantirati da su mali vremenski pečati ispred treba malo obraditi.

Kada se susretnete sa dizajnom univerzalnog sistema rang lista, ispituje se sposobnost dizajna sistema, ovde možete proširiti iz metodologije koju sam ranije naveo, pratite moje članke, akumulirajte iskustva, verujem da će prijatelji biti sve spretniji.

PS:

U stvari, kroz ceo proces analize možete otkriti, pitanja scenarija su zapravo primena onih "pamćenih standardnih odgovora" i tehnologija koje ste naučili, stoga prilikom učenja pitanja scenarija možete postavljati pitanja o "pamćenim standardnim odgovorima", malo kao kada ne možete zapamtiti reči pa čitate članke, pri čitanju članka upamtite "pamćene standardne odgovore", u gore procesu analize sam i na nekoliko mesta nasumično postavljao pitanja o "pamćenim standardnim odgovorima". U procesu dizajna sistema rang listi korišćen je MQ, da li prijatelji mogu uz to pregledati "pamćene standardne odgovore" o MQ?

(1) Kako garantovati idempotentnost poruka MQ?

(2) Šta su push i pull modeli MQ?

(3) Kako garantovati da se poruke MQ ne gube?

……

Sve ovo su stvari koje me sigurno pitaju kada na intervjuu naiđem na Redis, ne nužno pitaju sve, ali bar su tri od jedne…

Dobro, ako imate bilo kakvih pitanja dobrodošli u sekciju komentara da diskutujemo. Uključujući ali ne ograničavajući se na mišljenje o korekciji pisanja članaka, sledeći sadržaj za deljenje (iskustvo intervjua, izlaz znanja, deljenje iskustva itd.), već ste došli do ovoga, kliknite besplatno praćenje i lajk nije previše zatraženo

#Pitanje scenarija##Pamćeni standardni odgovori##Intervju##Letnja praksa##Proljećna regrutacija#

Upozorenje

Pretplati se na časopis

Referenca: https://www.nowcoder.com/discuss/734195711469707264, priredio: Marko Marković