Laajamittainen verkkosovellukset ovat edenneet pitkälle kahden edellisen vuosikymmenen aikana. Nämä innovaatiot ovat muuttaneet käsityksemme ohjelmistokehityksestä. Esimerkiksi Facebook, Instagram ja Twitter ovat kaikki skaalautuvia alustoja.
Nämä järjestelmät on rakennettava hallitsemaan valtavia liikenne- ja datamääriä, koska miljardit ihmiset käyttävät niitä samanaikaisesti kaikkialla maailmassa. Tämä on kun Järjestelmäsuunnittelu siirtyy kuvaan.
Tietyt kriteerit täyttävän järjestelmän arkkitehtuurin, rajapintojen ja datan määrittämistä kutsutaan järjestelmäsuunnitteluksi. Yhtenäisten ja tehokkaiden järjestelmien avulla järjestelmäsuunnittelu täyttää yrityksesi tai organisaatiosi vaatimukset.
Kun yrityksesi tai organisaatiosi on määrittänyt kriteerinsä, voit alkaa sisällyttää niitä fyysiseen järjestelmäsuunnitteluun, joka vastaa kuluttajien vaatimuksia.
Valitsetpa sitten räätälöidyn kehityksen, kaupalliset ratkaisut tai näiden kahden yhdistelmän, järjestelmän suunnittelu määrittää sen, kuinka rakennat sen.
Tarkastelemme yksityiskohtaisesti Twitter-aikajanan järjestelmäsuunnittelua tässä viestissä, jossa on opetusohjelma. Aloitetaan.
Vaihe 1: Esittele käyttötapaukset ja rajoitukset
Käytä tapausta
- Käyttäjä lataa twiitin.
- Palvelu lähettää push-ilmoituksia ja sähköposteja twiittien seuraajille.
- Käyttäjän aikajanaa tarkastellaan (käyttäjän toiminta)
- Käyttäjä katsoo kodin aikajanaa (käyttäjän seuraamien ihmisten toiminta)
- Käyttäjä hakee avainsanat.
- Palvelu on todella saavutettavissa.
Soveltamisalan ulkopuolella
- Tweetit lähetetään Twitter Firehose -palveluun ja muihin tätä palvelua käyttäviin streameihin.
- Palvelu poistaa twiittejä käyttäjän näkyvyysasetusten perusteella.
- Jos käyttäjä ei myöskään seuraa henkilöä, jolle on vastattu, piilota vastaus.
- Huomioi "piilota uudelleentwiittaukset" -vaihtoehto.
- Analytics
Rajoitukset & oletukset
Valtion oletukset
- Liikenne ei ole jakautunut tasaisesti.
- Twiitin lähettämisen pitäisi olla helppoa.
- Ellei sinulla ole miljoonia seuraajia, twiitin lähettämisen kaikille seuraajillesi pitäisi olla nopeaa.
- Aktiivisia käyttäjiä on 100 miljoonaa.
- 15 miljardia twiittiä kuukaudessa tai 500 miljoonaa twiittiä joka päivä
- Jokaisella twiitillä on keskimäärin 10 toimituskertaa.
- Fanout lähettää joka päivä 5 miljardia twiittiä.
- Fanout lähettää 150 miljardia twiittiä joka kuukausi.
- 250 miljardia kuukausittaista lukupyyntöä
- 10 miljardia kuukausittaista hakua
Aikajana
- Aikajanalla tulee olla helppo navigoida.
- Twitter on enemmän lukemista kuin kirjoittamista.
- Optimoi nopeaa twiitin lukemista varten
- Tweettien käyttö vie aikaa.
Haku
- Hakuprosessin tulee olla nopea.
- Etsiminen vie aikaa.
Laske käyttö
Kunkin twiitin koko:
- 8 tavua twiitin tunnus
- 32 tavua käyttäjätunnus
- 140 tavua tekstiä
- media – keskimäärin 10 kt
- Yhteensä: ~10 kt
Joka kuukausi luodaan 150 Tt uutta twiittisisältöä.
- * 500 miljoonaa twiittiä joka päivä * 30 päivää kuukaudessa * 10 kt per twiitti
- Kolmessa vuodessa tuoretta twiittisisältöä on ollut 5.4 PB.
Sekunnissa on 100,000 XNUMX lukupyyntöä.
- * (400 pyyntöä sekunnissa / 1 miljardi pyyntöä kuukaudessa) 250 miljardia lukupyyntöä kuukaudessa
Jokaisessa sekunnissa on 6,000 XNUMX twiittiä.
- * (400 pyyntöä sekunnissa / 1 miljardi pyyntöä kuukaudessa) 15 miljardia twiittiä joka kuukausi
Fanoutissa lähetetään 60 tuhatta twiittiä sekunnissa.
- Fanout toimittaa 150 miljardia twiittiä kuukaudessa* (400 pyyntöä sekunnissa / 1 miljardi pyyntöä kuukaudessa).
4,000 tietopyyntöä sekunnissa
- * (400 pyyntöä sekunnissa / 1 miljardi pyyntöä kuukaudessa) 10 miljardia hakua kuukaudessa
Hyödyllinen muunnos
- Joka kuukausi kuluu 2.5 miljoonaa sekuntia.
- 2.5 miljoonaa pyyntöä kuukaudessa 1 pyyntö sekunnissa
- 100 miljoonaa pyyntöä kuukaudessa x 40 pyyntöä sekunnissa
- 1 miljardi pyyntöä kuukaudessa = 400 pyyntöä sekunnissa
Vaihe 2: Korkean tason kaavio
Vaihe 3: Peruskomponenttien selittäminen
Voisimme tallentaa käyttäjän omat twiitit täyttääksemme käyttäjän aikajanan (käyttäjän toiminta) relaatiotietokantaan, jos he lähettävät twiitin. Tweettien jakaminen ja kotiaikajanan kehittäminen (käyttäjän seuraamien henkilöiden toimintaa) on vaikeampaa.
Tyypillinen relaatiotietokanta hukkuisi tweettien jakaminen kaikille seuraajille (60 tuhatta twiittiä toimitetaan sekunnissa). Haluamme luultavasti valita nopeasti kirjoitettavan tietovaraston, kuten NoSQL-tietokannan tai muistivälimuistin.
1 Mt:n peräkkäinen lukeminen muistista kestää noin 250 mikrosekuntia, mutta SSD-levyltä lukeminen 4 kertaa ja levyltä 80 kertaa niin kauan.
Objektikauppaa voidaan käyttää tietojen, kuten kuvien ja videoiden, tallentamiseen.
- Verkkopalvelin, joka toimii käänteisenä välityspalvelimena, vastaanottaa tweetin asiakkaalta.
- Web-palvelin lähettää pyynnön Write API -palvelimelle.
- Write API tallentaa twiitin SQL-tietokantaan käyttäjän aikajanalla.
Write API ottaa yhteyttä Fan-Out-palveluun, ja se suorittaa seuraavat tehtävät.
- Löytää käyttäjän seuraajat välimuistista tekemällä kyselyn User Graph -palvelusta.
- Muistivälimuistiin twiitti tallennetaan käyttäjän seuraajien kotiaikajanalle.
- 1,000 1,000 seuraajaa = XNUMX XNUMX hakua ja lisäystä = O(n) -toiminto.
- Twiitti tallennetaan hakuhakemistopalveluun nopeaa hakua varten.
- Objektikauppaa käytetään median tallentamiseen.
- Lähettää push-hälytyksiä seuraajille ilmoituspalvelun kautta.
- Hälytysten lähettämiseen asynkronisesti se käyttää jonoa.
Voimme käyttää alkuperäistä Redis-luetteloa, jolla on seuraava rakenne, jos muistivälimuistimme on Redis:
Käyttäjän kotiaikajana päivitettäisiin uudella twiitillä, joka tallennettaisiin muistivälimuistiin. Käytämme seuraavaa julkista REST-sovellusliittymää:
Käyttäjä näkee käyttäjän aikajanan.
- Web-palvelin vastaanottaa käyttäjän aikajanapyynnön asiakkaalta.
- Web-palvelin lähettää pyynnön Read API -palvelimelle.
- Read API kysyy SQL-tietokannasta käyttäjän aikakehystä.
REST API toimisi samalla tavalla kuin kotiaikajana, sillä poikkeuksella, että kaikki twiitit olisivat peräisin käyttäjältä eikä heidän seuraamilta ihmisiltä.
Käyttäjä hakee avainsanoja:
- Web-palvelin vastaanottaa hakupyynnön asiakkaalta.
- Web-palvelin lähettää pyynnön Search API -palvelimelle.
Vaihe 4: Twitterin aikajana
Aikajanan luominen on vaikea tehtävä. Tarvitaan aikajanan luova palvelin, joka linkittää verkkoon tai sovelluspalvelimiin.
Joka kerta kun käyttäjä kirjautuu sisään, aikajanapalvelu pitää kirjaa käyttäjien uusimmista twiiteistä seuraajien taulukossa ja päivittää tai päivittää käyttäjän aikajanan.
Emme ota käyttöön minkäänlaista sijoitusjärjestelmää; sen sijaan oletamme, että käyttäjän seuraajien 5 parasta twiittiä esitetään aikajanalla luomisajan järjestyksessä. Voimme ylläpitää 50 twiitin päivitysrajaa. Lopetamme edelleen päivittämisen tai aikajanan luomisen kynnyksen saavuttamisen jälkeen, kunnes käyttäjä päivittää sivun.
Korkeat viiveet ja suorituskykyongelmat johtuvat reaaliaikaisen käyttäjäsyötteen luomisesta. Sen sijaan offline-streamin luominen, joka voidaan esittää välittömästi, on paras tapa parantaa suorituskykyä. Suorita omistettuja aikajanapalvelimia, jotka lähettävät ping-kutsuja sovelluspalvelimelle säännöllisesti päivittääkseen syötteen sen luomisajan perusteella.
Luokittelualgoritmin tulee ottaa huomioon keskeiset signaalit ja antaa painoarvoa sen varmistamiseksi, että käyttäjän aikajanalla ei hallitse materiaalia yhdestä tai useammasta hänen seuraamastaan tilistä.
Tarkemmin sanottuna voimme valita minkä tahansa syötekohteen osuvuuteen liittyviä ominaisuuksia, kuten tykkäyksiä, kommentteja, jakoja ja päivitysaikaa. Kutakin näistä kriteereistä tulisi käyttää twiitin arvioimiseen, ja sitten tätä arvoa tulisi käyttää twiittien näyttämiseen aikajanalla.
Pitäisikö meidän jatkuvasti varoittaa käyttäjiä, kun heidän uutissyötteensä uutta sisältöä tulee saataville? Käyttäjien mielestä on hyödyllistä saada varoitus, kun uutta tietoa tulee saataville. Mobiililaitteilla, kun tiedon käyttö on kuitenkin melko kallista, se voi hukata kaistanleveyttä.
Tämän seurauksena voimme olla välittämättä dataa mobiililaitteisiin ja sen sijaan antaa käyttäjien "Pull to Refresh" -toiminnon uusille julkaisuille.
Vaihe 5: Skaalaussuunnittelu
Mahdollinen pullonkaula on Fanout-palvelu. Twitter-käyttäjien, joilla on miljoonia seuraajia, on odotettava useita minuutteja, jotta heidän twiittinsä julkaistaan. Tämä voi aiheuttaa kilpailun vastausten kanssa twiittiin, jonka voisimme välttää järjestämällä twiitit uudelleen tarjoushetkellä.
Voisimme myös estää tviittien leviämisen ihmisiltä, joilla on paljon seuraajia. Sen sijaan voimme etsiä twiittejä paljon seuratuilta henkilöiltä, integroida hakutulokset käyttäjän kotiaikajanan tuloksiin ja sitten järjestää twiitit uudelleen syöttöhetkellä.
Muita parannuksia ovat:
- Säilytä vain muutama sata twiittiä muistivälimuistissa kutakin kotiaikajanaa kohden.
- Muistivälimuistiin tallennetaan vain aktiivisten käyttäjien kotiaikajanan tiedot.
- Voimme rekonstruoida kronologian SQL-tietokannasta, jos käyttäjä ei ole ollut aktiivinen edellisten 30 päivän aikana.
- Selvittääksesi, kuka käyttäjä on, käytä User Graph -palvelua.
- Lisää tweetit muistivälimuistiin hakemalla ne SQL-tietokannasta.
- Tweet Info Service voi säästää vain kuukauden verran twiittejä.
- Käyttäjätietopalvelussa vain aktiiviset käyttäjät tallennetaan.
- Jotta viive pysyisi alhaisena, hakuklusterin on todennäköisesti säilytettävä twiitit muistissa.
Yhteenveto
Vaikka Twitter on suuri organisaatio, sillä on parempi ymmärrystä järjestelmän suunnittelusta. Tein parhaani tarjotakseni sinulle korkean tason yleiskatsauksen Twitterin aikajanasta.
Toivottavasti sait siitä hyödyllistä tietoa ja voit käyttää sitä hyödyksi.
Jätä vastaus