Aplicațiile online la scară largă au parcurs un drum lung în ultimele două decenii. Aceste inovații ne-au modificat percepțiile despre dezvoltarea software-ului. Facebook, Instagram și Twitter, de exemplu, sunt toate platforme scalabile.
Aceste sisteme trebuie să fie construite pentru a gestiona volume masive de trafic și date, deoarece miliarde de oameni le folosesc în același timp în întreaga lume. Acesta este momentul în care proiectarea sistemului intra în imagine.
Procesul de stabilire a arhitecturii, interfețelor și datelor pentru un sistem care îndeplinește anumite criterii este cunoscut sub numele de proiectare a sistemului. Prin sisteme coezive și eficiente, proiectarea sistemului satisface cerințele afacerii sau organizației dumneavoastră.
Odată ce compania sau organizația dvs. și-a determinat criteriile, puteți începe să le încorporați într-un design de sistem fizic care să răspundă cerințelor consumatorilor dvs.
Indiferent dacă alegeți să optați pentru dezvoltare personalizată, soluții comerciale sau o combinație a celor două, modul în care vă proiectați sistemul va determina modul în care îl construiți.
Vom arunca o privire detaliată asupra designului sistemului al cronologiei Twitter în această postare, completată cu un tutorial. Să începem.
Pasul 1: Prezentați cazul de utilizare și constrângerile
Utilizare caz
- Un utilizator încarcă un tweet.
- Serviciul trimite notificări push și e-mail-uri adepților tweet-urilor.
- Este vizualizată cronologia utilizatorului (activitate de la utilizator)
- Utilizatorul se uită la cronologia de acasă (activitatea persoanelor pe care utilizatorul le urmărește)
- Cuvintele cheie sunt căutate de utilizator.
- Serviciul este cu adevărat accesibil.
Fara scop
- Tweeturile sunt trimise către Twitter Firehose și alte fluxuri folosind acest serviciu.
- Serviciul elimină tweet-urile pe baza setărilor de vizibilitate ale utilizatorului.
- Dacă utilizatorul nu urmărește și persoana căreia i s-a răspuns, ascundeți răspunsul.
- Observați opțiunea „ascunde retweeturile”.
- Google Analytics
Constrângeri și ipoteze
Ipoteze de stat
- Traficul nu este dispersat în mod egal.
- Ar trebui să fie simplu să trimiți un tweet.
- Cu excepția cazului în care aveți milioane de urmăritori, trimiterea unui tweet tuturor adepților dvs. ar trebui să fie rapidă.
- Există 100 de milioane de utilizatori activi.
- 15 miliarde de tweet-uri în fiecare lună sau 500 de milioane de tweet-uri în fiecare zi
- Fiecare tweet are un fanout de 10 livrare în medie.
- În fiecare zi, fanout oferă 5 miliarde de tweet-uri.
- Fanout livrează 150 de miliarde de tweet-uri în fiecare lună.
- 250 de miliarde de solicitări lunare de citire
- 10 miliarde de căutări lunare
Companiei
- Cronologia ar trebui să fie ușor de navigat.
- Twitter este mai mult despre citit decât despre scris.
- Optimizați pentru citirea rapidă a tweet-urilor
- Consumul de Tweet necesită timp.
Caută
- Procesul de căutare ar trebui să fie rapid.
- E nevoie de timp să cauți.
Calculați utilizarea
Dimensiunea fiecărui tweet:
- ID de tweet de 8 octeți
- 32 de octeți user-id
- 140 de octeți de text
- media – medie de 10 KB
- Total: ~10 KB
În fiecare lună, sunt generați 150 TB de conținut proaspăt de tweet.
- * 500 de milioane de tweet-uri în fiecare zi * 30 de zile pe lună * 10 KB per tweet
- În trei ani, au existat 5.4 PB de conținut de tweet proaspăt.
Există 100,000 de solicitări de citire în fiecare secundă.
- * (400 de solicitări pe secundă / 1 miliard de solicitări pe lună) 250 de miliarde de solicitări de citire în fiecare lună
Există 6,000 de tweet-uri în fiecare secundă.
- * (400 de solicitări pe secundă / 1 miliard de solicitări pe lună) 15 miliarde de tweet-uri în fiecare lună
Pe fanout, 60 de mii de tweet-uri sunt trimise în fiecare secundă.
- Fanout livrează 150 de miliarde de tweet-uri în fiecare lună* (400 de solicitări pe secundă / 1 miliard de solicitări pe lună).
4,000 de solicitări de informații în fiecare secundă
- * (400 de solicitări pe secundă / 1 miliard de solicitări pe lună) 10 miliarde de căutări în fiecare lună
O conversie utilă
- În fiecare lună, trec 2.5 milioane de secunde.
- 2.5 milioane de solicitări pe lună la 1 cerere pe secundă
- 100 de milioane de solicitări pe lună x 40 de solicitări pe secundă
- 1 miliard de solicitări pe lună = 400 de solicitări pe secundă
Pasul 2: Diagrama de nivel înalt
Pasul 3: Explicarea componentelor de bază
Am putea salva propriile tweet-uri ale utilizatorului pentru a popula cronologia utilizatorului (activitatea utilizatorului) într-o bază de date relațională dacă trimit un tweet. Este mai dificil să difuzați tweet-uri și să dezvoltați cronologia de acasă (activitate de la persoanele pe care utilizatorul le urmărește).
O bază de date relațională tipică ar fi copleșită prin difuzarea de tweet-uri către toți adepții (60 de mii de tweet-uri livrate în fiecare secundă). Probabil că vom dori să mergem cu o stocare de date cu scriere rapidă, cum ar fi o bază de date NoSQL sau Memory Cache.
Citirea secvenţială a 1 MB din memorie durează aproximativ 250 de microsecunde, dar citirea de pe SSD durează de 4 ori mai mult, iar citirea de pe disc durează de 80 de ori mai mult.
Un depozit de obiecte poate fi folosit pentru a stoca date precum imagini și videoclipuri.
- Serverul Web, care acționează ca un proxy invers, primește un tweet de la Client.
- Solicitarea este trimisă către serverul Write API de către serverul web.
- API-ul Write salvează tweet-ul într-o bază de date SQL în cronologia utilizatorului.
Serviciul Fan-Out este contactat de API-ul Write și efectuează următoarele sarcini.
- Găsește adepții utilizatorului în memoria cache interogând serviciul User Graph.
- Într-un cache de memorie, tweet-ul este salvat în cronologia de acasă a urmăritorilor utilizatorului.
- 1,000 de urmăritori = 1,000 de căutări și inserări = operațiune O(n).
- Tweetul este salvat în Serviciul de index de căutare pentru căutare rapidă.
- Magazinul de obiecte este folosit pentru a stoca medii.
- Trimite alerte push către urmăritori prin Serviciul de notificare.
- Pentru a trimite alerte asincron, folosește o coadă.
Putem utiliza o listă Redis nativă cu următoarea structură dacă memoria cache este Redis:
Cronologia de acasă a utilizatorului va fi actualizată cu noul tweet, care va fi stocat în memoria cache. Vom folosi următorul API REST public:
Cronologia utilizatorului este vizualizată de utilizator.
- Serverul Web primește o cerere de cronologie a utilizatorului de la Client.
- Solicitarea este trimisă către serverul Read API de către serverul web.
- API-ul Read interogează baza de date SQL pentru intervalul de timp al utilizatorului.
API-ul REST ar funcționa similar cu cronologia de acasă, cu excepția faptului că toate tweet-urile ar proveni de la utilizator, mai degrabă decât de la oamenii pe care îi urmăresc.
Un utilizator caută cuvinte cheie:
- Serverul Web primește o cerere de căutare de la Client.
- Solicitarea este trimisă către serverul Search API de către serverul web.
Pasul 4: cronologia Twitter
Crearea cronologiei este o sarcină dificilă. Este necesar un server generator de cronologie care se conectează la serverele web sau de aplicații.
De fiecare dată când un utilizator se conectează, serviciul de cronologie ține evidența celor mai noi tweet-uri de la utilizatori din tabelul urmăritorilor și actualizează sau reîmprospătează cronologia utilizatorului.
Nu implementăm niciun fel de sistem de clasare aici; în schimb, presupunem că primele 5 tweet-uri de la adepții utilizatorului sunt prezentate în cronologia în ordinea timpului de creare. Putem menține o limită de reîmprospătare de 50 de tweet-uri. Încă oprim reîmprospătarea sau construirea unei cronologie după ce pragul respectiv este atins până când utilizatorul reîmprospătează pagina.
Problemele legate de latența ridicată și de performanță vor veni din crearea fluxului de utilizatori live. În schimb, crearea unui flux offline care poate fi prezentat instantaneu este cea mai bună modalitate de a îmbunătăți performanța. Rulați servere de cronologie dedicate care pun ping la serverul de aplicații în mod regulat pentru a reîmprospăta fluxul în funcție de momentul în care a fost creat.
Algoritmul de clasare ar trebui să ia în considerare semnalele esențiale și să ofere pondere pentru a garanta că cronologia unui utilizator nu este dominată de material din unul sau mai multe dintre conturile pe care le urmăresc.
Mai precis, putem alege funcții legate de relevanța oricărui element de feed, cum ar fi numărul de aprecieri, comentarii, distribuiri și timpul de actualizare. Fiecare dintre aceste criterii ar trebui folosit pentru a evalua tweet-ul, iar apoi acel rang ar trebui folosit pentru a afișa tweet-urile pe cronologia.
Ar trebui să alertăm în mod constant utilizatorii când devine disponibil conținut nou pentru fluxul lor de știri? Utilizatorii pot considera că este benefic să fie alertați atunci când devin disponibile date noi. Cu toate acestea, pe dispozitivele mobile, atunci când utilizarea datelor este destul de costisitoare, se poate risipi lățime de bandă.
Drept urmare, putem opta pentru a nu transmite date pe dispozitivele mobile și, în schimb, le permitem utilizatorilor să „trage pentru a reîmprospăta” pentru postări noi.
Pasul 5: scalarea designului
Un posibil blocaj este Serviciul Fanout. Utilizatorii Twitter cu milioane de urmăritori vor trebui să aștepte câteva minute pentru ca tweet-urile lor să fie difuzate. Acest lucru ar putea provoca o cursă cu răspunsuri la tweet, pe care am putea-o evita reordonând tweet-urile la momentul difuzării.
De asemenea, am putea preveni răspândirea tweet-urilor de la persoane cu un număr mare de urmăritori. În schimb, putem face o căutare pentru tweet-uri de la persoane foarte urmărite, integrăm rezultatele căutării cu rezultatele cronologice de acasă ale utilizatorului și apoi reordonăm tweet-urile la momentul difuzării.
Îmbunătățirile suplimentare includ:
- Păstrați doar câteva sute de tweet-uri în memoria cache pentru fiecare cronologie de acasă.
- În memoria cache, sunt salvate numai informațiile cronologice de acasă ale utilizatorilor activi.
- Putem reconstrui cronologia din baza de date SQL dacă un utilizator nu a fost activ în ultimele 30 de zile.
- Pentru a afla cine este utilizatorul, utilizați serviciul User Graph.
- Adăugați tweet-urile în memoria cache prin preluarea lor din baza de date SQL.
- Serviciul Tweet Info poate economisi doar o lună de tweet-uri.
- În Serviciul de informații despre utilizator, sunt salvați numai utilizatorii activi.
- Pentru a menține latența scăzută, Clusterul de căutare ar trebui cel mai probabil să mențină tweet-urile în memorie.
Concluzie
Deși Twitter este o organizație mare, are o organizație mai bună înțelegerea proiectării sistemului. Am făcut tot posibilul să vă ofer o prezentare generală la nivel înalt a cronologiei Twitter.
Sper că ați obținut informații utile din ea și că le puteți folosi.
Lasă un comentariu