Liela mēroga tiešsaistes lietojumprogrammas pēdējo divu desmitgažu laikā ir sasniegušas garu ceļu. Šie jauninājumi ir mainījuši mūsu priekšstatus par programmatūras izstrādi. Piemēram, Facebook, Instagram un Twitter ir mērogojamas platformas.
Šīs sistēmas ir jāveido, lai pārvaldītu milzīgus trafika un datu apjomus, jo miljardiem cilvēku tās vienlaikus izmanto visā pasaulē. Tas ir tad, kad sistēmas projektēšana ienāk attēlā.
Arhitektūras, saskarņu un datu izveides process sistēmai, kas atbilst noteiktiem kritērijiem, ir pazīstams kā sistēmas projektēšana. Pateicoties saskaņotām un efektīvām sistēmām, sistēmas dizains apmierina jūsu uzņēmuma vai organizācijas prasības.
Kad jūsu uzņēmums vai organizācija ir noteikusi savus kritērijus, varat sākt tos iekļaut fiziskās sistēmas dizainā, kas atbilst jūsu patērētāju prasībām.
Neatkarīgi no tā, vai izvēlaties izmantot individuālu izstrādi, komerciālus risinājumus vai abu kombināciju, sistēmas izveides veids būs atkarīgs no sistēmas izveides.
Šajā ziņā mēs detalizēti apskatīsim Twitter laika skalas sistēmas dizainu, kā arī apmācību. Sāksim.
1. darbība. Ieskicējiet lietošanas gadījumu un ierobežojumus
Izmantot gadījumu
- Lietotājs augšupielādē tvītu.
- Pakalpojums sūta push paziņojumus un e-pastus tvītu sekotājiem.
- Tiek skatīta lietotāja laika skala (lietotāja darbība)
- Lietotājs aplūko mājas laika skalu (darbības no personām, kurām lietotājs seko)
- Atslēgvārdus meklē lietotājs.
- Pakalpojums ir patiešām pieejams.
Ārpus darbības jomas
- Izmantojot šo pakalpojumu, tvīti tiek nosūtīti uz Twitter Firehose un citām straumēm.
- Pakalpojums noņem tvītus, pamatojoties uz lietotāja redzamības iestatījumiem.
- Ja lietotājs arī neseko personai, uz kuru tiek atbildēts, paslēpiet atbildi.
- Ievērojiet opciju "slēpt retvītus".
- Analytics
Ierobežojumi un pieņēmumi
Stāvokļa pieņēmumi
- Satiksme nav vienādi izkliedēta.
- Tvīta nosūtīšanai jābūt vienkāršai.
- Ja vien jums nav miljoniem sekotāju, tvīta nosūtīšanai visiem saviem sekotājiem vajadzētu būt ātri.
- Ir 100 miljoni aktīvo lietotāju.
- 15 miljardi tvītu katru mēnesi vai 500 miljoni tvītu katru dienu
- Katram tvītam ir vidēji 10 piegādes.
- Katru dienu fanout piegādā 5 miljardus tvītu.
- Fanout katru mēnesi piegādā 150 miljardus tvītu.
- 250 miljardi ikmēneša lasīšanas pieprasījumu
- 10 miljardi meklējumu mēnesī
Timeline
- Laika skalā jābūt viegli orientējamai.
- Twitter ir vairāk par lasīšanu, nevis rakstīšanu.
- Optimizējiet ātrai tvītu lasīšanai
- Tvītu patēriņš ir laikietilpīgs.
Meklēt
- Meklēšanas procesam jābūt ātram.
- Meklēšana ir laikietilpīga.
Aprēķināt lietojumu
Katra tvīta lielums:
- 8 baitu tvīta id
- 32 baiti lietotāja ID
- 140 baiti teksta
- medijs – vidēji 10 KB
- Kopā: ~10 KB
Katru mēnesi tiek ģenerēti 150 TB svaiga tvītu satura.
- * 500 miljoni tvītu katru dienu * 30 dienas mēnesī * 10 KB par vienu tvītu
- Trīs gadu laikā ir bijis 5.4 PB svaiga tvīta satura.
Katru sekundi ir 100,000 XNUMX lasīšanas pieprasījumu.
- * (400 pieprasījumu sekundē / 1 miljards pieprasījumu mēnesī) 250 miljardi lasīšanas pieprasījumu katru mēnesi
Katru sekundi ir 6,000 tvītu.
- * (400 pieprasījumu sekundē / 1 miljards pieprasījumu mēnesī) 15 miljardi tvītu katru mēnesi
Fanout tīklā ik sekundi tiek nosūtīti 60 tūkstoši tvītu.
- Fanout katru mēnesi nodrošina 150 miljardus tvītu* (400 pieprasījumu sekundē / 1 miljards pieprasījumu mēnesī).
4,000 informācijas pieprasījumu katru sekundi
- * (400 pieprasījumu sekundē / 1 miljards pieprasījumu mēnesī) 10 miljardi meklējumu katru mēnesi
Dažas noderīgas konversijas
- Katru mēnesi paiet 2.5 miljoni sekunžu.
- 2.5 miljoni pieprasījumu mēnesī ar 1 pieprasījumu sekundē
- 100 miljoni pieprasījumu mēnesī x 40 pieprasījumi sekundē
- 1 miljards pieprasījumu mēnesī = 400 pieprasījumu sekundē
2. darbība: augsta līmeņa diagramma
3. darbība: galveno komponentu izskaidrošana
Mēs varētu saglabāt paša lietotāja tvītus, lai relāciju datu bāzē aizpildītu lietotāja laika skalu (lietotāja darbību), ja viņš iesniedz tvītu. Ir grūtāk piegādāt tvītus un izstrādāt mājas laika skalu (darbības no personām, kurām lietotājs seko).
Tipiska relāciju datu bāze būtu pārslogota, izplatot tvītus visiem sekotājiem (katru sekundi tiek piegādāti 60 tūkstoši tvītu). Mēs, iespējams, vēlēsimies izmantot ātras rakstīšanas datu krātuvi, piemēram, NoSQL datu bāzi vai atmiņas kešatmiņu.
1 MB secīga nolasīšana no atmiņas aizņem aptuveni 250 mikrosekundes, bet nolasīšana no SSD prasa 4 reizes ilgāku laiku, bet nolasīšana no diska — 80 reizes ilgāk.
Objektu veikalu var izmantot, lai saglabātu datus, piemēram, attēlus un videoklipus.
- Tīmekļa serveris, kas darbojas kā apgrieztais starpniekserveris, saņem tvītu no Klienta.
- Tīmekļa serveris pieprasījumu nosūta Write API serverim.
- Write API saglabā tvītu SQL datu bāzē lietotāja laika skalā.
Ar Fan-Out pakalpojumu sazinās Write API, un tas veic tālāk norādītos uzdevumus.
- Atrod lietotāja sekotājus atmiņas kešatmiņā, vaicājot User Graph Service.
- Atmiņas kešatmiņā tvīts tiek saglabāts lietotāja sekotāju sākuma laika skalā.
- 1,000 sekotāju = 1,000 meklējumu un ievietojumu = O(n) darbība.
- Tvīts tiek saglabāts Search Index Service ātrai meklēšanai.
- Objektu veikals tiek izmantots multivides glabāšanai.
- Nosūta push brīdinājumus sekotājiem, izmantojot paziņojumu pakalpojumu.
- Lai asinhroni nosūtītu brīdinājumus, tas izmanto rindu.
Mēs varam izmantot vietējo Redis sarakstu ar šādu struktūru, ja mūsu atmiņas kešatmiņa ir Redis:
Lietotāja mājas laika skala tiktu atjaunināta ar jauno tvītu, kas tiktu saglabāts atmiņas kešatmiņā. Mēs izmantosim šādu publisko REST API:
Lietotāja laika skalu skatās lietotājs.
- Web serveris saņem lietotāja laika skalas pieprasījumu no Klienta.
- Tīmekļa serveris pieprasījumu nosūta Lasīšanas API serverim.
- Lasīšanas API vaicā SQL datu bāzi par lietotāja laika periodu.
REST API darbotos līdzīgi kā mājas laika skala, ar izņēmumu, ka visi tvīti būtu sūtīti no lietotāja, nevis no cilvēkiem, kuriem viņi seko.
Lietotājs meklē atslēgvārdus:
- Web serveris saņem no Klienta meklēšanas pieprasījumu.
- Tīmekļa serveris pieprasījumu nosūta Search API serverim.
4. darbība: Twitter laika skala
Laika skalas izveide ir grūts uzdevums. Nepieciešams laika skalas ģenerēšanas serveris, kas veido saites uz tīmekļa vai lietojumprogrammu serveriem.
Katru reizi, kad lietotājs pierakstās, laika skalas pakalpojums sekotāju tabulā seko jaunākajiem lietotāju tvītiem un atjaunina vai atsvaidzina lietotāja laika skalu.
Mēs šeit neieviešam nekāda veida vērtēšanas sistēmu; tā vietā mēs pieņemam, ka 5 populārākie tvīti no lietotāja sekotājiem tiek parādīti laika skalā izveides laika secībā. Mēs varam saglabāt 50 tvītu atsvaidzināšanas ierobežojumu. Mēs joprojām pārtraucam atsvaidzināt vai veidot laika skalu pēc šī sliekšņa sasniegšanas, līdz lietotājs atsvaidzina lapu.
Lielas latentuma un veiktspējas problēmas radīs tiešraides lietotāju plūsmas izveide. Tā vietā bezsaistes straumes izveide, ko var uzreiz prezentēt, ir labākais veids, kā uzlabot veiktspēju. Palaidiet īpašus laika skalas serverus, kas regulāri ping lietojumprogrammu serverim, lai atsvaidzinātu plūsmu, pamatojoties uz tās izveides laiku.
Randēšanas algoritmam ir jāņem vērā būtiski signāli un jānodrošina svars, lai garantētu, ka lietotāja laika skalā nedominē materiāls no viena vai vairākiem kontiem, kuriem viņi seko.
Precīzāk, mēs varam izvēlēties funkcijas, kas saistītas ar jebkura plūsmas vienuma atbilstību, piemēram, atzīmju Patīk, komentāru, kopīgošanas gadījumu skaitu un atjaunināšanas laiku. Katrs no šiem kritērijiem ir jāizmanto, lai novērtētu tvītu, un pēc tam šis rangs ir jāizmanto, lai rādītu tvītus laika skalā.
Vai mums pastāvīgi jābrīdina lietotāji, kad viņu ziņu plūsmai kļūst pieejams jauns saturs? Lietotājiem var būt noderīgi saņemt brīdinājumu, kad kļūst pieejami jauni dati. Tomēr mobilajās ierīcēs, kad datu izmantošana ir diezgan dārga, tas var tērēt joslas platumu.
Rezultātā mēs varam izvēlēties nepārsūtīt datus uz mobilajām ierīcēm un tā vietā ļaut lietotājiem “Pavilkt, lai atsvaidzinātu”, lai iegūtu jaunus ziņojumus.
5. darbība: mērogošanas dizains
Iespējamais sašaurinājums ir Fanout pakalpojums. Twitter lietotājiem ar miljoniem sekotāju būs jāgaida vairākas minūtes, līdz tiks publicēti viņu tvīti. Tas var izraisīt sacensību ar atbildēm uz tvītu, no kā mēs varētu izvairīties, pārkārtojot tvītus servēšanas laikā.
Mēs varētu arī novērst tvītu izplatīšanu no cilvēkiem, kuriem ir liels sekotāju skaits. Tā vietā mēs varam meklēt tvītus no ļoti sekotām personām, integrēt meklēšanas rezultātus ar lietotāja mājas laika skalas rezultātiem un pēc tam pārkārtot tvītus servēšanas laikā.
Papildu uzlabojumi ietver:
- Katrai mājas laika skalai atmiņas kešatmiņā saglabājiet tikai dažus simtus tvītu.
- Atmiņas kešatmiņā tiek saglabāta tikai aktīvo lietotāju mājas laika skalas informācija.
- Mēs varam rekonstruēt hronoloģiju no SQL datu bāzes, ja lietotājs nav bijis aktīvs iepriekšējo 30 dienu laikā.
- Lai uzzinātu, kas ir lietotājs, izmantojiet User Graph Service.
- Pievienojiet tvītus atmiņas kešatmiņai, izgūstot tos no SQL datu bāzes.
- Tvītu informācijas pakalpojums var ietaupīt tikai mēneša tvītus.
- Lietotāja informācijas pakalpojumā tiek saglabāti tikai aktīvie lietotāji.
- Lai saglabātu zemu latentumu, meklēšanas klasterim, visticamāk, būs jāuztur atmiņā tvīti.
Secinājumi
Lai gan Twitter ir liela organizācija, tai ir labāka izpratne par sistēmas dizainu. Es darīju visu iespējamo, lai sniegtu jums augsta līmeņa pārskatu par Twitter laika skalu.
Ceru, ka no tā ieguvāt noderīgu informāciju un varēsiet to izmantot.
Atstāj atbildi