Velike online aplikacije prešle su dug put u prethodna dva desetljeća. Te su inovacije promijenile naše percepcije razvoja softvera. Facebook, Instagram i Twitter, na primjer, sve su skalabilne platforme.
Ovi sustavi moraju biti izgrađeni za upravljanje ogromnim količinama prometa i podataka budući da ih milijarde ljudi koriste u isto vrijeme diljem svijeta. Ovo je kada dizajn sustava ulazi u sliku.
Proces uspostavljanja arhitekture, sučelja i podataka za sustav koji zadovoljava određene kriterije poznat je kao dizajn sustava. Kroz kohezivne i učinkovite sustave, dizajn sustava zadovoljava zahtjeve vašeg poslovanja ili organizacije.
Nakon što vaša tvrtka ili organizacija odredi svoje kriterije, možete ih početi ugrađivati u dizajn fizičkog sustava koji zadovoljava zahtjeve vaših potrošača.
Bilo da se odlučite za razvoj po narudžbi, komercijalna rješenja ili kombinaciju to dvoje, način na koji dizajnirate svoj sustav će odrediti kako ćete ga izgraditi.
Detaljno ćemo pogledati dizajn sustava Twitter vremenske trake u ovom postu, zajedno s vodičem. Započnimo.
Korak 1: Navedite slučaj upotrebe i ograničenja
Upotrijebite slučaj
- Korisnik učitava tweet.
- Usluga šalje push obavijesti i e-poštu pratiteljima tweetova.
- Pregledava se korisnička vremenska traka (aktivnost korisnika)
- Korisnik gleda kućnu vremensku traku (aktivnost osoba koje korisnik prati)
- Ključne riječi pretražuje korisnik.
- Usluga je stvarno dostupna.
Izvan dosega
- Tweetovi se šalju na Twitter Firehose i druge streamove koristeći ovu uslugu.
- Usluga uklanja tweetove na temelju postavki vidljivosti korisnika.
- Ako korisnik također ne prati osobu kojoj se odgovara, sakrijte odgovor.
- Promatrajte opciju 'sakrij retweets'.
- analitika
Ograničenja i pretpostavke
Državne pretpostavke
- Promet nije jednako raspoređen.
- Trebalo bi biti jednostavno poslati tweet.
- Osim ako nemate milijune sljedbenika, slanje tweeta svim svojim sljedbenicima trebalo bi biti brzo.
- Ima 100 milijuna aktivnih korisnika.
- 15 milijardi tweetova svaki mjesec ili 500 milijuna tweetova svaki dan
- Svaki tweet ima prosječno 10 isporuka.
- Svaki dan fanout isporučuje 5 milijardi tweetova.
- Fanout isporučuje 150 milijardi tweetova svaki mjesec.
- 250 milijardi mjesečnih zahtjeva za čitanje
- 10 milijardi mjesečnih pretraga
Timeline
- Vremenskom trakom treba se lako kretati.
- Twitter se više bavi čitanjem nego pisanjem.
- Optimizirajte za brzo čitanje tweeta
- Potrošnja tvita oduzima mnogo vremena.
Traži
- Proces traženja trebao bi biti brz.
- Pretraživanje je dugotrajno.
Izračunajte upotrebu
Veličina svakog tweeta:
- 8 bajtova tweet id
- 32 bajta korisnički ID
- 140 bajtova teksta
- mediji – prosječno 10 KB
- Ukupno: ~10 KB
Svaki mjesec generira se 150 TB svježeg tweet sadržaja.
- * 500 milijuna tweetova svaki dan * 30 dana mjesečno * 10 KB po tweetu
- U tri godine bilo je 5.4 PB svježeg tweet sadržaja.
Svake sekunde ima 100,000 zahtjeva za čitanje.
- * (400 zahtjeva u sekundi / 1 milijarda zahtjeva mjesečno) 250 milijardi zahtjeva za čitanje svaki mjesec
Svake sekunde ima 6,000 tweetova.
- * (400 zahtjeva u sekundi / 1 milijarda zahtjeva mjesečno) 15 milijardi tweetova svaki mjesec
Na fanoutu se svake sekunde pošalje 60 tisuća tweetova.
- Fanout isporučuje 150 milijardi tweetova svaki mjesec* (400 zahtjeva u sekundi / 1 milijarda zahtjeva mjesečno).
4,000 zahtjeva za informacijama svake sekunde
- * (400 zahtjeva u sekundi / 1 milijarda zahtjeva mjesečno) 10 milijardi pretraživanja svaki mjesec
Neka korisna konverzija
- Svaki mjesec prođe 2.5 milijuna sekundi.
- 2.5 milijuna zahtjeva mjesečno uz 1 zahtjev u sekundi
- 100 milijuna zahtjeva mjesečno x 40 zahtjeva u sekundi
- 1 milijarda zahtjeva mjesečno = 400 zahtjeva u sekundi
Korak 2: Dijagram visoke razine
Korak 3: Objašnjavanje osnovnih komponenti
Mogli bismo spremiti korisnikove vlastite tweetove kako bismo popunili korisničku vremensku traku (aktivnost korisnika) u relacijsku bazu podataka ako pošalju tweet. Teže je isporučiti tweetove i razviti kućnu vremensku traku (aktivnost pojedinaca koje korisnik prati).
Tipična relacijska baza podataka bila bi zatrpana širenjem tweetova svim sljedbenicima (60 tisuća tweetova isporučeno svake sekunde). Vjerojatno ćemo htjeti ići s brzom pohranom podataka kao što je NoSQL baza podataka ili Memory Cache.
Čitanje 1 MB uzastopno iz memorije traje otprilike 250 mikrosekundi, ali čitanje sa SSD-a traje 4 puta duže, a čitanje s diska traje 80 puta duže.
Spremište objekata može se koristiti za pohranu podataka kao što su slike i video zapisi.
- Web poslužitelj, koji djeluje kao obrnuti proxy, prima tweet od Klijenta.
- Web poslužitelj šalje zahtjev Write API poslužitelju.
- Write API sprema tweet u SQL bazu podataka na vremenskoj traci korisnika.
Uslugu Fan-Out kontaktira API Write i ona obavlja sljedeće zadatke.
- Pronalazi sljedbenike korisnika u predmemoriji memorije tako što postavlja upit za uslugu grafa korisnika.
- Na predmemoriji memorije, tweet se sprema u kućnu vremensku traku korisnikovih sljedbenika.
- 1,000 pratitelja = 1,000 pregleda i umetanja = O(n) operacija.
- Tweet se sprema u Search Index Service za brzo pretraživanje.
- Spremište objekata koristi se za pohranu medija.
- Šalje push upozorenja sljedbenicima putem usluge obavijesti.
- Za asinkrono slanje upozorenja koristi se red čekanja.
Možemo koristiti izvorni Redis popis sa sljedećom strukturom ako je naša predmemorija memorije Redis:
Korisnikova kućna vremenska traka ažurirala bi se novim tweetom, koji bi bio pohranjen u predmemoriju memorije. Koristit ćemo sljedeći javni REST API:
Korisnik pregledava vremensku traku korisnika.
- Web poslužitelj prima zahtjev za vremensku traku korisnika od Klijenta.
- Web poslužitelj šalje zahtjev na Read API poslužitelj.
- Read API postavlja upite SQL bazi podataka za korisnički vremenski okvir.
REST API bi radio slično kao i kućna vremenska traka, s iznimkom da bi svi tweetovi potjecali od korisnika, a ne od ljudi koje prate.
Korisnik traži ključne riječi:
- Web poslužitelj prima zahtjev za pretraživanje od Klijenta.
- Web poslužitelj šalje zahtjev poslužitelju Search API.
Korak 4: Twitter vremenska traka
Kreiranje vremenske trake težak je zadatak. Potreban je poslužitelj za generiranje vremenske trake koji se povezuje na web ili aplikacijske poslužitelje.
Svaki put kada se korisnik prijavi, usluga vremenske trake održava praćenje najnovijih tweetova korisnika u tablici pratitelja i ažurira ili osvježava korisnikovu vremensku traku.
Ovdje ne implementiramo nikakav sustav rangiranja; umjesto toga, pretpostavljamo da je prvih 5 tweetova korisnika sljedbenika prikazano na vremenskoj traci prema vremenu kreiranja. Možemo zadržati ograničenje osvježavanja od 50 tvitova. I dalje prestajemo osvježavati ili izrađivati vremensku traku nakon što se dosegne taj prag dok korisnik ne osvježi stranicu.
Visoka latencija i brige o performansama dolazi od kreiranja feeda korisnika uživo. Umjesto toga, stvaranje izvanmrežnog streama koji se može odmah predstaviti najbolji je način za poboljšanje performansi. Pokrenite namjenske poslužitelje vremenske trake koji redovito pinguju poslužitelj aplikacija kako bi osvježili feed na temelju vremena kada je stvoren.
Algoritam za rangiranje trebao bi uzeti u obzir ključne signale i dati težinu kako bi se jamčilo da korisnikovom vremenskom trakom ne dominira materijal s jednog ili više računa koje prate.
Točnije, možemo odabrati značajke povezane s relevantnošću bilo koje stavke feeda, kao što su broj lajkova, komentara, dijeljenja i vrijeme ažuriranja. Svaki od ovih kriterija trebao bi se koristiti za ocjenjivanje tweeta, a zatim bi se taj rang trebao koristiti za prikazivanje tweetova na vremenskoj traci.
Trebamo li stalno upozoravati korisnike kada novi sadržaj za njihov newsfeed postane dostupan? Korisnici mogu smatrati korisnim biti upozoreni kada novi podaci postanu dostupni. Na mobilnim uređajima, međutim, kada je korištenje podataka prilično skupo, može izgubiti propusnost.
Kao rezultat toga, možemo odlučiti da ne prosljeđujemo podatke na mobilne uređaje i umjesto toga dopuštamo korisnicima da "Povuku za osvježavanje" za nove objave.
Korak 5: Dizajn skaliranja
Potencijalno usko grlo je usluga Fanout. Korisnici Twittera s milijunima sljedbenika morat će pričekati nekoliko minuta da se njihovi tweetovi objave. To bi moglo uzrokovati utrku s odgovorima na tweet, što bismo mogli izbjeći ponovnim redoslijedom tweetova u vrijeme posluživanja.
Također bismo mogli spriječiti širenje tweetova ljudi s velikim brojem pratitelja. Umjesto toga, možemo pretražiti tweetove osoba s velikim brojem praćenja, integrirati rezultate pretraživanja s rezultatima kućne vremenske trake korisnika, a zatim promijeniti redoslijed tweetova u vrijeme posluživanja.
Dodatna poboljšanja uključuju:
- Zadržite samo nekoliko stotina tweetova u predmemoriji memorije za svaku kućnu vremensku traku.
- U predmemoriji memorije spremaju se samo podaci vremenske trake aktivnih korisnika.
- Možemo rekonstruirati kronologiju iz SQL baze podataka ako korisnik nije bio aktivan u prethodnih 30 dana.
- Da biste saznali tko je korisnik, upotrijebite uslugu User Graph.
- Dodajte tweetove u predmemoriju memorije tako što ćete ih preuzeti iz SQL baze podataka.
- Usluga Tweet Info može uštedjeti samo mjesec dana tweetova.
- U korisničkom Info servisu spremaju se samo aktivni korisnici.
- Kako bi latencija bila niska, Search Cluster bi najvjerojatnije trebao zadržati tweetove u memoriji.
Zaključak
Iako je Twitter velika organizacija, ima bolju razumijevanje dizajna sustava. Dao sam sve od sebe da vam pružim pregled vremenske trake na Twitteru na visokoj razini.
Nadam se da ste iz njega dobili korisne informacije i da ih možete dobro iskoristiti.
Ostavi odgovor