Obsežne spletne aplikacije so v zadnjih dveh desetletjih zelo napredovale. Te inovacije so spremenile naše dojemanje razvoja programske opreme. Facebook, Instagram in Twitter so na primer razširljive platforme.
Ti sistemi morajo biti zgrajeni za upravljanje ogromnih količin prometa in podatkov, saj jih uporablja milijarde ljudi po vsem svetu hkrati. To je takrat načrtovanje sistema vstopi v sliko.
Postopek vzpostavitve arhitekture, vmesnikov in podatkov za sistem, ki izpolnjuje določene kriterije, je znan kot načrtovanje sistema. S kohezivnimi in učinkovitimi sistemi zasnova sistema izpolnjuje zahteve vašega podjetja ali organizacije.
Ko vaše podjetje ali organizacija določi svoja merila, jih lahko začnete vključevati v fizično zasnovo sistema, ki ustreza zahtevam vaših potrošnikov.
Ne glede na to, ali se odločite za razvoj po meri, komercialne rešitve ali kombinacijo obojega, bo od tega, kako boste načrtovali svoj sistem, odvisno, kako ga boste zgradili.
V tej objavi si bomo podrobno ogledali sistemsko zasnovo časovnice Twitter, skupaj z vadnico. Začnimo.
1. korak: oris primera uporabe in omejitev
Uporaba primera
- Uporabnik naloži tvit.
- Storitev pošilja potisna obvestila in e-pošto sledilcem tvitov.
- Prikazana je uporabnikova časovnica (dejavnost uporabnika)
- Uporabnik si ogleda domačo časovnico (dejavnost ljudi, ki jih uporabnik spremlja)
- Ključne besede išče uporabnik.
- Storitev je res dostopna.
Izven obsega
- Tviti se pošiljajo v Twitter Firehose in druge tokove, ki uporabljajo to storitev.
- Storitev odstrani tvite glede na nastavitve vidnosti uporabnika.
- Če uporabnik tudi ne spremlja osebe, ki ji je odgovoril, skrijte odgovor.
- Upoštevajte možnost »skrij ponovne tvite«.
- Analytics
Omejitve in predpostavke
Državne predpostavke
- Promet ni enakomerno razpršen.
- Pošiljanje tvita mora biti preprosto.
- Če nimate več milijonov sledilcev, bi moralo biti pošiljanje tvita vsem vašim sledilcem hitro.
- Aktivnih uporabnikov je 100 milijonov.
- 15 milijard tvitov vsak mesec ali 500 milijonov tvitov vsak dan
- Vsak tvit ima v povprečju 10 oddaj.
- Fanout vsak dan objavi 5 milijard tvitov.
- Fanout vsak mesec posreduje 150 milijard tvitov.
- 250 milijard mesečnih zahtev za branje
- 10 milijard mesečnih iskanj
Timeline
- Po časovnici mora biti enostavno krmarjenje.
- Twitter je bolj namenjen branju kot pisanju.
- Optimizirajte za hitro branje tvitov
- Poraba tvitov je zamudna.
Iskalnik
- Postopek iskanja mora biti hiter.
- Iskanje je zamudno.
Izračunajte porabo
Velikost vsakega tvita:
- 8-bajtni ID tvita
- 32 bajtov ID uporabnika
- 140 bajtov besedila
- mediji – povprečno 10 KB
- Skupaj: ~10 KB
Vsak mesec se ustvari 150 TB sveže vsebine tvitov.
- * 500 milijonov tvitov vsak dan * 30 dni na mesec * 10 KB na tvit
- V treh letih je bilo 5.4 PB sveže tvitne vsebine.
Vsako sekundo je 100,000 zahtev za branje.
- * (400 zahtev na sekundo / 1 milijarda zahtev na mesec) 250 milijard zahtev za branje vsak mesec
Vsako sekundo je 6,000 tvitov.
- * (400 zahtev na sekundo / 1 milijarda zahtev na mesec) 15 milijard tvitov vsak mesec
Na fanoutu je vsako sekundo poslanih 60 tisoč tvitov.
- Fanout vsak mesec dostavi 150 milijard tvitov* (400 zahtev na sekundo / 1 milijarda zahtev na mesec).
Vsako sekundo 4,000 zahtevkov za informacije
- * (400 zahtev na sekundo / 1 milijarda zahtev na mesec) 10 milijard iskanj vsak mesec
Nekaj uporabnih pretvorb
- Vsak mesec mine 2.5 milijona sekund.
- 2.5 milijona zahtev na mesec pri 1 zahtevi na sekundo
- 100 milijonov zahtevkov na mesec x 40 zahtevkov na sekundo
- 1 milijarda zahtevkov na mesec = 400 zahtevkov na sekundo
2. korak: Diagram visoke ravni
3. korak: Razlaga osnovnih komponent
Lahko bi shranili uporabnikove lastne tvite, da bi zapolnili uporabniško časovnico (dejavnost uporabnika) v relacijski bazi podatkov, če pošljejo tvit. Težje je pošiljati tvite in razvijati domačo časovnico (dejavnost posameznikov, ki jim uporabnik sledi).
Tipična relacijska podatkovna baza bi bila preobremenjena s širjenjem tvitov vsem sledilcem (60 tisoč tvitov, dostavljenih vsako sekundo). Verjetno se bomo želeli odločiti za shranjevanje podatkov s hitrim zapisovanjem, kot sta baza podatkov NoSQL ali predpomnilnik pomnilnika.
Zaporedno branje 1 MB iz pomnilnika traja približno 250 mikrosekund, vendar branje s SSD traja 4-krat dlje, branje z diska pa 80-krat dlje.
Shrambo predmetov lahko uporabite za shranjevanje podatkov, kot so slike in videoposnetki.
- Spletni strežnik, ki deluje kot obratni proxy, prejme tvit od odjemalca.
- Spletni strežnik pošlje zahtevo strežniku Write API.
- Write API shrani tvit v bazo podatkov SQL na časovni osi uporabnika.
API za pisanje vzpostavi stik s storitvijo Fan-Out in izvaja naslednje naloge.
- Poišče uporabnikove sledilce v predpomnilniku pomnilnika s poizvedovanjem storitve User Graph Service.
- V predpomnilniku pomnilnika se tweet shrani na domačo časovno premico uporabnikovih sledilcev.
- 1,000 sledilcev = 1,000 iskanj in vstavkov = O(n) operacij.
- Tvit je shranjen v storitvi Search Index Service za hitro iskanje.
- Object Store se uporablja za shranjevanje medijev.
- Pošilja potisna opozorila sledilcem prek storitve obveščanja.
- Za asinhrono pošiljanje opozoril uporablja čakalno vrsto.
Uporabimo lahko izvorni seznam Redis z naslednjo strukturo, če je naš predpomnilnik Redis:
Uporabnikova domača časovnica bi bila posodobljena z novim tvitom, ki bi bil shranjen v predpomnilniku pomnilnika. Uporabili bomo naslednji javni API REST:
Uporabniško časovnico si ogleduje uporabnik.
- Spletni strežnik od odjemalca prejme zahtevo po uporabniški časovnici.
- Spletni strežnik pošlje zahtevo strežniku Read API.
- Read API poizveduje v zbirki podatkov SQL za uporabniški časovni okvir.
REST API bi deloval podobno kot domača časovnica, z izjemo, da bi vsi tviti izvirali od uporabnika in ne od ljudi, ki mu sledijo.
Uporabnik išče ključne besede:
- Spletni strežnik od odjemalca prejme iskalno zahtevo.
- Spletni strežnik pošlje zahtevo strežniku Search API.
4. korak: časovnica Twitterja
Ustvarjanje časovnice je težka naloga. Potreben je strežnik za generiranje časovnice, ki je povezan s spletom ali aplikacijskimi strežniki.
Vsakič, ko se uporabnik prijavi, storitev časovne premice spremlja najnovejše tvite uporabnikov v tabeli sledilcev in posodobi ali osveži uporabnikovo časovno os.
Tu ne izvajamo nobenega sistema razvrščanja; namesto tega predpostavljamo, da je prvih 5 tvitov uporabnikovih sledilcev predstavljenih na časovnici po vrstnem redu glede na čas nastanka. Ohranimo lahko omejitev osveževanja 50 tvitov. Še vedno prenehamo z osveževanjem ali ustvarjanjem časovnice, potem ko je ta prag dosežen, dokler uporabnik ne osveži strani.
Visoka zakasnitev in pomisleki glede učinkovitosti bodo izvirali iz ustvarjanja virov uporabnikov v živo. Namesto tega je najboljši način za izboljšanje učinkovitosti ustvarjanje toka brez povezave, ki ga je mogoče takoj predstaviti. Zaženite namenske strežnike časovne premice, ki redno pingajo aplikacijski strežnik, da osvežijo vir glede na čas, ko je bil ustvarjen.
Algoritem za razvrščanje bi moral upoštevati ključne signale in zagotoviti težo, da bi zagotovil, da na časovni premici uporabnika ne prevladuje gradivo iz enega ali več računov, ki jim sledi.
Natančneje, izberemo lahko funkcije, povezane z ustreznostjo katerega koli elementa vira, kot je število všečkov, komentarjev, skupnih rab in čas posodobitve. Vsako od teh meril je treba uporabiti za ocenjevanje tvita, nato pa to uvrstitev uporabiti za prikaz tvitov na časovni osi.
Ali naj nenehno opozarjamo uporabnike, ko postane na voljo nova vsebina za njihov vir novic? Uporabnikom je lahko koristno, če so opozorjeni, ko so na voljo novi podatki. Na mobilnih napravah, ko je uporaba podatkov precej draga, lahko zapravlja pasovno širino.
Posledično se lahko odločimo, da podatkov ne pošiljamo v mobilne naprave in namesto tega uporabnikom omogočimo »Potegnite za osvežitev« za nove objave.
5. korak: Oblikovanje skaliranja
Morebitno ozko grlo je storitev Fanout. Uporabniki Twitterja z milijoni sledilcev bodo morali počakati nekaj minut, da bodo njihovi tviti objavljeni. To bi lahko povzročilo tekmo z odgovori na tvit, čemur bi se lahko izognili s prerazporeditvijo tvitov v času serviranja.
Prav tako bi lahko preprečili širjenje tvitov ljudi z velikim številom sledilcev. Namesto tega lahko poiščemo tvite posameznikov, ki jih zelo spremljajo, integriramo rezultate iskanja z rezultati na domači časovni premici uporabnika in nato prerazporedimo tvite v času serviranja.
Dodatne izboljšave vključujejo:
- V predpomnilniku za vsako domačo časovnico shranite le nekaj sto tvitov.
- V predpomnilniku pomnilnika so shranjene samo informacije o domači časovnici aktivnih uporabnikov.
- Iz podatkovne baze SQL lahko rekonstruiramo kronologijo, če uporabnik ni bil aktiven v zadnjih 30 dneh.
- Če želite ugotoviti, kdo je uporabnik, uporabite storitev User Graph Service.
- Dodajte tvite v predpomnilnik pomnilnika tako, da jih pridobite iz zbirke podatkov SQL.
- Informacijska služba za tvite lahko shrani le tvite za mesec dni.
- V uporabniški informacijski storitvi so shranjeni samo aktivni uporabniki.
- Da bi zakasnitev ostala nizka, bi iskalna gruča najverjetneje morala vzdrževati tvite v pomnilniku.
zaključek
Čeprav je Twitter velika organizacija, ima boljšo razumevanje zasnove sistema. Po najboljših močeh sem se potrudil, da vam zagotovim pregled časovnice Twitterja na visoki ravni.
Upam, da ste iz nje pridobili koristne informacije in jih lahko koristno uporabili.
Pustite Odgovori