Grootskaalse aanlyntoepassings het die afgelope twee dekades ver gevorder. Hierdie innovasies het ons persepsies van sagteware-ontwikkeling verander. Facebook, Instagram en Twitter is byvoorbeeld almal skaalbare platforms.
Hierdie stelsels moet gebou word om massiewe volumes verkeer en data te bestuur aangesien miljarde mense dit terselfdertyd regoor die wêreld gebruik. Dit is wanneer stelsel ontwerp kom in die prentjie.
Die proses om die argitektuur, koppelvlakke en data te vestig vir 'n stelsel wat aan sekere kriteria voldoen, staan bekend as stelselontwerp. Deur samehangende en doeltreffende stelsels voldoen stelselontwerp aan die eise van jou besigheid of organisasie.
Sodra jou maatskappy of organisasie sy kriteria bepaal het, kan jy dit begin inkorporeer in 'n fisiese stelselontwerp wat aan jou verbruikers se vereistes voldoen.
Of jy kies om te gaan met pasgemaakte ontwikkeling, kommersiële oplossings, of 'n kombinasie van die twee, hoe jy jou stelsel ontwerp sal bepaal hoe jy dit bou.
Ons sal 'n gedetailleerde blik op die stelselontwerp van die Twitter-tydlyn in hierdie plasing neem, kompleet met 'n tutoriaal. Laat ons begin.
Stap 1: Skets gebruiksgevalle en -beperkings
Gebruik die saak
- 'n Gebruiker laai 'n tweet op.
- Die diens stuur stootkennisgewings en e-posse aan volgelinge van tweets.
- Die gebruiker se tydlyn word bekyk (aktiwiteit vanaf die gebruiker)
- Die gebruiker kyk na die tuistydlyn (aktiwiteit van mense wat die gebruiker volg)
- Sleutelwoorde word deur die gebruiker gesoek.
- Die diens is regtig toeganklik.
Buite omvang
- Tweets word na die Twitter Firehose en ander strome gestuur deur hierdie diens te gebruik.
- Die diens verwyder tweets op grond van die sigbaarheidinstellings van die gebruiker.
- As die gebruiker nie ook die persoon volg wat geantwoord word nie, versteek die antwoord.
- Let op die 'versteek retweets'-opsie.
- Analytics
Beperkings en aannames
Staatsaannames
- Die verkeer is nie eweredig versprei nie.
- Dit behoort eenvoudig te wees om 'n tweet te stuur.
- Tensy jy miljoene volgelinge het, moet dit vinnig wees om 'n tweet aan al jou volgelinge te stuur.
- Daar is 100 miljoen aktiewe gebruikers.
- 15 miljard twiets elke maand of 500 miljoen twiets elke dag
- Elke tweet het gemiddeld 'n fanout van 10 aflewerings.
- Elke dag lewer fanout 5 miljard tweets.
- Fanout lewer 150 miljard tweets elke maand.
- 250 miljard maandelikse leesversoeke
- 10 miljard maandelikse soektogte
Tydlyn
- Die tydlyn moet maklik wees om te navigeer.
- Twitter gaan meer oor lees as skryf.
- Optimaliseer vir vinnige tweet-lees
- Tweetverbruik is tydrowend.
Soek
- Die soekproses behoort vinnig te wees.
- Dit is tydrowend om te soek.
Bereken gebruik
Grootte van elke tweet:
- 8 grepe tweet-ID
- 32 grepe gebruiker-ID
- 140 grepe teks
- media – gemiddeld 10 KB
- Totaal: ~10 KB
Elke maand word 150 TB se vars tweet-inhoud gegenereer.
- * 500 miljoen twiets elke dag * 30 dae per maand * 10 KB per twiet
- In drie jaar was daar 5.4 PB se vars tweet-inhoud.
Daar is 100,000 XNUMX leesversoeke elke sekonde.
- * (400 versoeke per sekonde / 1 miljard versoeke per maand) 250 miljard leesversoeke elke maand
Daar is 6,000 XNUMX twiets elke sekonde.
- * (400 versoeke per sekonde / 1 miljard versoeke per maand) 15 miljard twiets elke maand
Op fanout word 60 duisend twiets elke sekonde gestuur.
- Fanout lewer 150 miljard tweets elke maand* (400 versoeke per sekonde / 1 miljard versoeke per maand).
4,000 XNUMX versoeke vir inligting elke sekonde
- * (400 versoeke per sekonde / 1 miljard versoeke per maand) 10 miljard soektogte elke maand
'n Paar nuttige omskakeling
- Elke maand gaan 2.5 miljoen sekondes verby.
- 2.5 miljoen versoeke per maand teen 1 versoek per sekonde
- 100 miljoen versoeke per maand x 40 versoeke per sekonde
- 1 miljard versoeke per maand = 400 versoeke per sekonde
Stap 2: Hoëvlakdiagram
Stap 3: Verduidelik kernkomponente
Ons kan die gebruiker se eie twiets stoor om die gebruiker se tydlyn (aktiwiteit vanaf die gebruiker) in 'n relasionele databasis te vul as hulle 'n twiet indien. Dit is moeiliker om twiets te lewer en die tuistydlyn te ontwikkel (aktiwiteit van individue wat die gebruiker volg).
'n Tipiese relasionele databasis sal oorweldig word deur tweets aan alle volgelinge uit te waai (60 duisend tweets gelewer elke sekonde). Ons sal waarskynlik wil gaan met 'n vinnige-skryf-databerging soos 'n NoSQL-databasis of Memory Cache.
Om 1 MB opeenvolgend uit die geheue te lees, neem ongeveer 250 mikrosekondes, maar lees vanaf SSD neem 4 keer so lank, en lees vanaf skyf neem 80 keer so lank.
'n Object Store kan gebruik word om data soos beelde en video's te stoor.
- Die webbediener, wat as 'n omgekeerde instaanbediener optree, ontvang 'n twiet van die kliënt.
- Die versoek word deur die webbediener na die Write API-bediener gestuur.
- Die Write API stoor die tweet na 'n SQL-databasis in die gebruiker se tydlyn.
Die Fan-Out-diens word gekontak deur die Write API, en dit voer die volgende take uit.
- Vind die gebruiker se volgelinge in die geheuekas deur navraag te doen na die gebruikersgrafiekdiens.
- Op 'n geheuekas word die tweet in die tuistydlyn van die gebruiker se volgers gestoor.
- 1,000 1,000 volgers = XNUMX XNUMX opsoeke en invoegings = O(n) bewerking.
- Die tweet word in die Soekindeksdiens gestoor vir vinnige soektog.
- Die Object Store word gebruik om media te stoor.
- Stuur stootwaarskuwings aan volgelinge via die kennisgewingdiens.
- Om waarskuwings asynchronies uit te stuur, gebruik dit 'n tou.
Ons kan 'n inheemse Redis-lys met die volgende struktuur gebruik as ons geheuekas Redis is:
Die gebruiker se tuistydlyn sal opgedateer word met die nuwe tweet, wat in die geheuekas gestoor sal word. Ons sal die volgende publieke REST API gebruik:
Die gebruiker se tydlyn word deur die gebruiker bekyk.
- Die webbediener ontvang 'n gebruikertydlynversoek van die kliënt.
- Die versoek word deur die webbediener na die Lees API-bediener gestuur.
- Die Lees API vra na die SQL-databasis vir die gebruikertydraamwerk.
Die REST API sal soortgelyk aan die tuistydlyn werk, met die uitsondering dat alle tweets van die gebruiker sou afkomstig wees eerder as die mense wat hulle volg.
'n Gebruiker soek sleutelwoorde:
- Die webbediener ontvang 'n soekversoek van die kliënt.
- Die versoek word deur die webbediener na die Search API-bediener gestuur.
Stap 4: Twitter-tydlyn
Tydlynskepping is 'n moeilike taak. 'n Tydlyngenererende bediener wat na die web of toepassingsbedieners skakel, word vereis.
Elke keer as 'n gebruiker aanmeld, hou die tydlyndiens dop van die nuutste twiets van die gebruikers in die volger se tabel en dateer of verfris die gebruiker se tydlyn.
Ons implementeer geen soort rangordestelsel hier nie; in plaas daarvan neem ons aan dat die top 5 twiets van die gebruiker se volgelinge in die tydlyn aangebied word in volgorde van skeppingstyd. Ons kan 'n 50-tweet-verversingstydperk handhaaf. Ons hou steeds op om te verfris of 'n tydlyn te konstrueer nadat daardie drempel bereik is totdat die gebruiker die bladsy verfris.
Bekommernisse oor hoë vertraging en werkverrigting sal voortspruit uit die skepping van regstreekse gebruikersvoer. In plaas daarvan is die skep van 'n vanlyn stroom wat onmiddellik aangebied kan word die beste manier om prestasie te verbeter. Begin toegewyde tydlynbedieners wat die toepassingbediener op 'n gereelde basis ping om die stroom te verfris op grond van die tyd wat dit geskep is.
Die rangordealgoritme moet belangrike seine in ag neem en gewig gee om te verseker dat 'n gebruiker se tydlyn nie oorheers word deur materiaal van een of meer van die rekeninge wat hulle volg nie.
Meer presies, ons kan kenmerke kies wat verband hou met die relevansie van enige voeritem, soos die aantal laaiks, opmerkings, delings en opdateringstyd. Elkeen van hierdie kriteria moet gebruik word om die twiet te gradeer, en dan moet daardie rang gebruik word om twiets op die tydlyn te wys.
Moet ons gebruikers voortdurend waarsku wanneer nuwe inhoud vir hul nuusvoer beskikbaar word? Gebruikers kan dit voordelig vind om gewaarsku te word wanneer nuwe data beskikbaar word. Op mobiele toestelle, wanneer datagebruik egter redelik duur is, kan dit bandwydte mors.
Gevolglik kan ons kies om nie data na mobiele toestelle te stoot nie en eerder gebruikers toelaat om te "trek om te verfris" vir nuwe plasings.
Stap 5: Skaalontwerp
'n Potensiële bottelnek is die Fanout-diens. Twitter-gebruikers met miljoene volgelinge sal 'n paar minute moet wag vir hul twiets om uit te voer. Dit kan 'n wedloop met antwoorde op die twiet veroorsaak, wat ons kan vermy deur die tweets te herrangskik tydens dienstyd.
Ons kan ook verhoed dat tweets van mense met 'n groot aantal volgelinge versprei word. In plaas daarvan, kan ons 'n soektog na tweets doen van individue wat baie gevolg word, die soekresultate met die gebruiker se tuistydlynresultate integreer, en dan die tweets herrangskik tydens die bediening.
Bykomende verbeterings sluit in:
- Hou slegs 'n paar honderd twiets in die geheuekas vir elke tuistydlyn.
- In die geheuekas word slegs aktiewe gebruikers se tuistydlyninligting gestoor.
- Ons kan die chronologie vanaf die SQL-databasis rekonstrueer as 'n gebruiker nie in die voorafgaande 30 dae aktief was nie.
- Om uit te vind wie die gebruiker is, gebruik die Gebruikersgrafiekdiens.
- Voeg die tweets by die geheuekas deur dit uit die SQL-databasis te haal.
- Die Tweet Info Service kan net 'n maand se twiets bespaar.
- In die Gebruikersinligtingdiens word slegs aktiewe gebruikers gestoor.
- Om latency laag te hou, sal die Search Cluster heel waarskynlik die twiets in die geheue moet behou.
Gevolgtrekking
Alhoewel Twitter 'n groot organisasie is, het dit 'n beter begrip van stelselontwerp. Ek het my bes gedoen om jou 'n hoëvlakoorsig van die Twitter-tydlyn te gee.
Ek hoop jy het nuttige inligting daaruit gekry en dit goed kan gebruik.
Lewer Kommentaar