Suuremahulised veebirakendused on viimase kahe aastakümne jooksul jõudnud kaugele. Need uuendused on muutnud meie arusaamu tarkvaraarendusest. Näiteks Facebook, Instagram ja Twitter on kõik skaleeritavad platvormid.
Need süsteemid tuleb üles ehitada tohutute liiklus- ja andmemahtude haldamiseks, kuna miljardid inimesed kasutavad neid korraga kogu maailmas. See on siis, kui süsteemi disain siseneb pildile.
Teatud kriteeriumidele vastava süsteemi arhitektuuri, liideste ja andmete loomise protsessi nimetatakse süsteemikujunduseks. Ühtsete ja tõhusate süsteemide kaudu rahuldab süsteemikujundus teie ettevõtte või organisatsiooni nõudmised.
Kui teie ettevõte või organisatsioon on oma kriteeriumid kindlaks määranud, võite hakata neid lisama füüsilisse süsteemi disaini, mis vastab teie tarbijate nõudmistele.
Olenemata sellest, kas valite kohandatud arenduse, kommertslahendused või nende kahe kombinatsiooni, määrab selle, kuidas te oma süsteemi kavandate.
Selles postituses koos õpetusega vaatleme üksikasjalikult Twitteri ajaskaala süsteemikujundust. Alustame.
1. samm: kirjeldage kasutusjuhtumeid ja piiranguid
Kasutusjuhtum
- Kasutaja laadib üles säutsu.
- Teenus saadab säutsude jälgijatele push-teateid ja e-kirju.
- Vaadatakse kasutaja ajaskaala (kasutaja tegevus)
- Kasutaja vaatab kodu ajaskaala (kasutaja jälgitavate inimeste tegevus)
- Märksõnu otsib kasutaja.
- Teenus on tõesti kättesaadav.
Väljaspool ulatust
- Tweets saadetakse Twitter Firehose'i ja muudesse seda teenust kasutavatesse voogudesse.
- Teenus eemaldab säutsud kasutaja nähtavuse seadete alusel.
- Kui kasutaja ei jälgi ka isikut, kellele vastatakse, peitke vastus.
- Jälgige valikut "Peida retweets".
- Analytics
Piirangud ja eeldused
Riigi oletused
- Liiklus ei ole võrdselt hajutatud.
- Säutsu saatmine peaks olema lihtne.
- Kui teil pole miljoneid jälgijaid, peaks säutsu saatmine kõigile oma jälgijatele olema kiire.
- Aktiivseid kasutajaid on 100 miljonit.
- 15 miljardit säutsu iga kuu või 500 miljonit säutsu iga päev
- Iga säutsu edastamise maht on keskmiselt 10.
- Iga päev edastab fanout 5 miljardit säutsu.
- Fanout edastab iga kuu 150 miljardit säutsu.
- 250 miljardit igakuist lugemistaotlust
- 10 miljardit igakuist otsingut
Timeline
- Ajaskaalal peaks olema lihtne navigeerida.
- Twitter on rohkem lugemist kui kirjutamist.
- Optimeerige säutsu kiireks lugemiseks
- Tweetide tarbimine on aeganõudev.
Otsing
- Otsinguprotsess peaks olema kiire.
- Otsimine on aeganõudev.
Arvutage kasutust
Iga säutsu suurus:
- 8 baiti säutsu ID
- 32 baiti kasutajatunnus
- 140 baiti teksti
- meedia – keskmiselt 10 KB
- Kokku: ~10 KB
Iga kuu luuakse 150 TB värsket säutsu sisu.
- * 500 miljonit säutsu iga päev * 30 päeva kuus * 10 KB säutsu kohta
- Kolme aastaga on värsket säutsu sisu olnud 5.4 PB.
Igas sekundis esitatakse 100,000 XNUMX lugemistaotlust.
- * (400 päringut sekundis / 1 miljard päringut kuus) 250 miljardit lugemistaotlust kuus
Igas sekundis on 6,000 säutsu.
- * (400 päringut sekundis / 1 miljard päringut kuus) 15 miljardit säutsu iga kuu
Fanoutis saadetakse igas sekundis 60 tuhat säutsu.
- Fanout edastab iga kuu 150 miljardit säutsu* (400 päringut sekundis / 1 miljard päringut kuus).
4,000 teabepäringut sekundis
- * (400 päringut sekundis / 1 miljard päringut kuus) 10 miljardit otsingut kuus
Mõni kasulik konversioon
- Iga kuu möödub 2.5 miljonit sekundit.
- 2.5 miljonit päringut kuus, 1 päring sekundis
- 100 miljonit päringut kuus x 40 päringut sekundis
- 1 miljard päringut kuus = 400 päringut sekundis
2. samm: kõrgetasemeline diagramm
3. samm: põhikomponentide selgitamine
Võiksime salvestada kasutaja enda säutsud, et sisestada kasutaja ajaskaala (kasutaja tegevus) relatsiooniandmebaasi, kui ta säutsu esitab. Keerulisem on säutsude edastamine ja koduse ajaskaala arendamine (kasutaja jälgitavate isikute tegevus).
Tüüpiline relatsiooniandmebaas oleks üle jõu käiv säutsude edastamine kõigile jälgijatele (igas sekundis edastatakse 60 tuhat säutsu). Tõenäoliselt tahame kasutada kiiresti kirjutatavat andmesalvestust, näiteks NoSQL-i andmebaasi või mälu vahemälu.
1 MB järjestikuse mälust lugemiseks kulub ligikaudu 250 mikrosekundit, kuid SSD-lt lugemine võtab aega 4 korda ja kettalt lugemine 80 korda kauem.
Objektipoodi saab kasutada andmete (nt piltide ja videote) salvestamiseks.
- Veebiserver, mis toimib pöördpuhverserverina, saab Kliendilt säutsu.
- Veebiserver saadab päringu Write API serverisse.
- Write API salvestab säutsu kasutaja ajajoonel olevasse SQL-andmebaasi.
Write API võtab ühendust Fan-Out Service'iga ja see täidab järgmisi ülesandeid.
- Otsib kasutaja jälgijad mälu vahemälust, tehes päringu User Graph Service.
- Mälu vahemällu salvestatakse säuts kasutaja jälgijate kodusele ajaskaalale.
- 1,000 jälgijat = 1,000 otsingut ja lisamist = O(n) operatsioon.
- Säuts salvestatakse kiireks otsimiseks otsinguindeksi teenusesse.
- Objektipoodi kasutatakse meedia salvestamiseks.
- Saadab teavitusteenuse kaudu jälgijatele tõuketeateid.
- Märguannete asünkroonseks saatmiseks kasutab see järjekorda.
Kui meie mälu vahemälu on Redis, saame kasutada järgmise struktuuriga natiivset Redise loendit:
Kasutaja kodune ajaskaala uuendatakse uue säutsuga, mis salvestatakse mälu vahemällu. Kasutame järgmist avalikku REST API-t:
Kasutaja vaatab kasutaja ajaskaala.
- Veebiserver saab kliendilt kasutaja ajaskaala päringu.
- Veebiserver saadab päringu Read API serverile.
- Lugemise API küsib SQL-i andmebaasist kasutaja ajavahemikku.
REST API töötaks sarnaselt koduse ajaskaalaga, selle erandiga, et kõik säutsud pärinevad pigem kasutajalt kui inimestelt, keda nad jälgivad.
Kasutaja otsib märksõnu:
- Veebiserver saab Kliendilt otsingupäringu.
- Päringu saadab veebiserver Search API serverile.
4. samm: Twitteri ajaskaala
Ajaskaala loomine on keeruline ülesanne. Vaja on ajaskaala genereerivat serverit, mis loob lingid veebi- või rakendusserveritele.
Iga kord, kui kasutaja sisse logib, jälgib ajaskaala teenus jälgijate tabelis olevate kasutajate uusimaid säutse ning värskendab või värskendab kasutaja ajaskaala.
Me ei rakenda siin mingit järjestussüsteemi; selle asemel eeldame, et kasutaja jälgijate 5 parimat säutsu esitatakse ajaskaalal loomise aja järjekorras. Saame säilitada 50 säutsu värskendamise piiri. Pärast selle läve saavutamist lõpetame värskendamise või ajaskaala koostamise seni, kuni kasutaja lehte värskendab.
Suur latentsusaeg ja jõudlusprobleemid tulenevad reaalajas kasutajate voo loomisest. Selle asemel on parim viis jõudluse parandamiseks luua võrguühenduseta voogu, mida saab kohe esitada. Käivitage spetsiaalseid ajaskaala servereid, mis pingivad rakendusserverile regulaarselt, et värskendada voogu selle loomise ajal.
Järjestusalgoritm peaks võtma arvesse olulisi signaale ja tagama, et kasutaja ajaskaala ei domineeriks ühe või mitme jälgitava konto materjal.
Täpsemalt saame valida mis tahes vooüksuse asjakohasusega seotud funktsioone, nagu meeldimiste, kommentaaride, jagamiste arv ja värskendamise aeg. Kõiki neid kriteeriume tuleks kasutada säutsu hindamiseks ja seejärel säutsude kuvamiseks ajateljel seda järjestust.
Kas peaksime kasutajaid pidevalt hoiatama, kui nende uudistevoo uus sisu muutub kättesaadavaks? Kasutajate arvates on kasulik saada hoiatus, kui uued andmed muutuvad kättesaadavaks. Kui andmekasutus on aga mobiilseadmetes üsna kulukas, võib see ribalaiust raisata.
Selle tulemusena saame otsustada, et me ei edasta andmeid mobiilseadmetesse, vaid lubame kasutajatel uute postituste jaoks "Pull to Refresh".
5. samm: disaini skaleerimine
Võimalik kitsaskoht on Fanouti teenus. Miljonite jälgijatega Twitteri kasutajad peavad oma säutsude avaldamiseks mitu minutit ootama. See võib põhjustada säutsudele vastamisega võidujooksu, mida saaksime vältida säutsude serveerimisajal uuesti järjestamisega.
Samuti saaksime takistada paljude jälgijate arvuga inimeste säutsude levitamist. Selle asemel võime otsida sageli jälgitavate isikute säutse, integreerida otsingutulemused kasutaja kodu ajaskaala tulemustega ja seejärel säutsu serveerimisajal ümber järjestada.
Täiendavad täiustused hõlmavad järgmist:
- Hoidke mälu vahemälus ainult paarsada säutsu iga koduse ajaskaala kohta.
- Mälu vahemällu salvestatakse ainult aktiivsete kasutajate kodu ajaskaala teave.
- Saame kronoloogia SQL-i andmebaasist rekonstrueerida, kui kasutaja pole olnud aktiivne viimase 30 päeva jooksul.
- Et teada saada, kes on kasutaja, kasutage kasutajagraafiku teenust.
- Lisage säutsud mälu vahemällu, hankides need SQL-i andmebaasist.
- Säutsuteabe teenus võib säästa vaid ühe kuu säutsudest.
- Kasutajateabe teenuses salvestatakse ainult aktiivsed kasutajad.
- Latentsuse madalana hoidmiseks peaks otsinguklaster tõenäoliselt säutsud mälus säilitama.
Järeldus
Kuigi Twitter on suur organisatsioon, on sellel parem arusaam süsteemi disainist. Andsin endast parima, et anda teile Twitteri ajajoonest kõrgetasemeline ülevaade.
Loodan, et saite sellest kasulikku teavet ja saate seda hästi kasutada.
Jäta vastus