A nagyszabású online alkalmazások nagy utat tettek meg az elmúlt két évtizedben. Ezek az újítások megváltoztatták a szoftverfejlesztésről alkotott felfogásunkat. A Facebook, az Instagram és a Twitter például mind méretezhető platformok.
Ezeket a rendszereket hatalmas forgalom és adatmennyiség kezelésére kell felépíteni, mivel emberek milliárdjai használják őket egyszerre világszerte. Ez az, amikor rendszertervezés belép a képre.
A bizonyos kritériumoknak megfelelő rendszer architektúrájának, interfészeinek és adatainak létrehozásának folyamatát rendszertervezésnek nevezzük. Az összefüggő és hatékony rendszereken keresztül a rendszertervezés kielégíti vállalkozása vagy szervezete igényeit.
Miután vállalata vagy szervezete meghatározta a kritériumait, elkezdheti beépíteni azokat egy olyan fizikai rendszerbe, amely megfelel a fogyasztói igényeknek.
Függetlenül attól, hogy az egyedi fejlesztést, kereskedelmi megoldásokat vagy a kettő kombinációját választja, a rendszer megtervezése határozza meg, hogyan építi fel azt.
Ebben a bejegyzésben egy oktatóanyaggal kiegészítve részletesen megvizsgáljuk a Twitter idővonalának rendszertervét. Kezdjük el.
1. lépés: Vázolja fel a használati esetet és a korlátozásokat
Használási eset
- Egy felhasználó feltölt egy tweetet.
- A szolgáltatás push értesítéseket és e-maileket küld a tweetek követőinek.
- A felhasználó idővonalának megtekintése (a felhasználó tevékenysége)
- A felhasználó megnézi az otthoni idővonalat (a felhasználó által követett személyek tevékenysége)
- A kulcsszavakat a felhasználó keresi.
- A szolgáltatás valóban elérhető.
Hatáskörön kívül
- A tweeteket a rendszer elküldi a Twitter Firehose-nak és a szolgáltatást használó egyéb adatfolyamoknak.
- A szolgáltatás a felhasználó láthatósági beállításai alapján eltávolítja a tweeteket.
- Ha a felhasználó nem követi a megválaszolt személyt, rejtse el a választ.
- Vegye figyelembe a „retweetek elrejtése” opciót.
- Elemzések
Megszorítások és feltételezések
Állami feltételezések
- A forgalom nem egyenletesen oszlik el.
- Egyszerűnek kell lennie egy tweet küldésének.
- Hacsak nincs több millió követője, gyorsan el kell küldenie egy tweetet az összes követőjének.
- 100 millió aktív felhasználó van.
- 15 milliárd tweet havonta vagy 500 millió tweet minden nap
- Minden tweet átlagosan 10-es lesz.
- A fanout minden nap 5 milliárd tweetet küld.
- A Fanout havonta 150 milliárd tweetet küld.
- 250 milliárd havi olvasási kérelem
- 10 milliárd havi keresés
Network TwentyOne Global
- Az idővonalon könnyen navigálhatónak kell lennie.
- A Twitter inkább az olvasásról szól, mint az írásról.
- Optimalizálás a tweet gyors olvasásához
- A tweet-felhasználás időigényes.
Keresés
- A keresési folyamatnak gyorsnak kell lennie.
- Időigényes a keresés.
Számítsa ki a felhasználást
Minden tweet mérete:
- 8 bájtos tweet azonosító
- 32 bájtos felhasználói azonosító
- 140 bájt szöveg
- média – átlagosan 10 KB
- Összesen: ~10 KB
Minden hónapban 150 TB friss tweet tartalom jön létre.
- * 500 millió tweet minden nap * havi 30 napon * 10 KB tweetenként
- Három év alatt 5.4 PB friss tweet tartalom volt.
Minden másodpercben 100,000 XNUMX olvasási kérés érkezik.
- * (400 kérés másodpercenként / 1 milliárd kérés havonta) 250 milliárd olvasási kérelem havonta
Minden másodpercben 6,000 tweet érkezik.
- * (400 kérés másodpercenként / 1 milliárd kérés havonta) 15 milliárd tweet havonta
A fanouton másodpercenként 60 ezer tweet érkezik.
- A Fanout havonta 150 milliárd tweetet küld* (400 kérés/másodperc / 1 milliárd kérés havonta).
4,000 információkérés másodpercenként
- * (400 kérés másodpercenként / 1 milliárd kérés havonta) 10 milliárd keresés havonta
Néhány hasznos átalakítás
- Minden hónapban 2.5 millió másodperc telik el.
- 2.5 millió kérés havonta, 1 kérés másodpercenként
- 100 millió kérés havonta x 40 kérés másodpercenként
- 1 milliárd kérés havonta = 400 kérés másodpercenként
2. lépés: Magas szintű diagram
3. lépés: Az alapvető összetevők magyarázata
Menthetjük a felhasználó saját tweetjeit, hogy feltöltsük a felhasználói idővonalat (a felhasználó tevékenysége) egy relációs adatbázisba, ha tweetet küldenek. Nehezebb tweeteket küldeni és az otthoni idővonalat fejleszteni (a felhasználó által követett személyek tevékenysége).
Egy tipikus relációs adatbázist túlterhelne, ha tweeteket juttatnának el minden követőhöz (másodpercenként 60 ezer tweet érkezik). Valószínűleg olyan gyorsan írható adattárolót szeretnénk választani, mint a NoSQL adatbázis vagy a memória gyorsítótár.
1 MB sorozatos olvasása a memóriából nagyjából 250 mikroszekundumot vesz igénybe, de SSD-ről 4-szer, lemezről pedig 80-szor annyi.
Az Object Store használható adatok, például képek és videók tárolására.
- A webszerver, amely fordított proxyként működik, tweetet kap az Ügyféltől.
- A kérést a webszerver küldi el a Write API szervernek.
- A Write API a tweetet egy SQL-adatbázisba menti a felhasználó idővonalán.
A Write API felveszi a kapcsolatot a Fan-Out Service-vel, és az alábbi feladatokat látja el.
- A User Graph Service lekérdezésével megkeresi a felhasználó követőit a memória-gyorsítótárban.
- A memória-gyorsítótárban a tweet a felhasználó követőinek otthoni idővonalára kerül mentésre.
- 1,000 követő = 1,000 keresés és beillesztés = O(n) művelet.
- A tweet a keresési index szolgáltatásba kerül a gyors keresés érdekében.
- Az Object Store a média tárolására szolgál.
- Push riasztásokat küld a követőknek az értesítési szolgáltatáson keresztül.
- A riasztások aszinkron kiküldéséhez egy várólistát használ.
Használhatunk natív Redis listát a következő szerkezettel, ha a memória-gyorsítótárunk Redis:
A felhasználó otthoni idővonala frissülne az új tweettel, amelyet a memória gyorsítótárban tárolnak. A következő nyilvános REST API-t fogjuk használni:
A felhasználói idővonalat a felhasználó tekinti meg.
- A webszerver felhasználói idővonal kérést kap az Ügyféltől.
- A kérést a webszerver elküldi a Read API szervernek.
- A Read API lekérdezi az SQL-adatbázist a felhasználói időkeretre vonatkozóan.
A REST API az otthoni idővonalhoz hasonlóan működne, azzal az eltéréssel, hogy minden tweet a felhasználótól származik, nem pedig az általa követett emberektől.
A felhasználó a következő kulcsszavakra keres:
- A webszerver keresési kérést kap az Ügyféltől.
- A kérést a webszerver elküldi a Search API szervernek.
4. lépés: Twitter idővonal
Az idővonal létrehozása nehéz feladat. Szükség van egy idővonal-generáló szerverre, amely a webre vagy az alkalmazáskiszolgálókra hivatkozik.
Minden alkalommal, amikor egy felhasználó bejelentkezik, az idővonal-szolgáltatás nyomon követi a felhasználók legújabb tweetjeit a követők táblázatában, és frissíti vagy frissíti a felhasználó idővonalát.
Itt semmiféle rangsorolási rendszert nem alkalmazunk; ehelyett azt feltételezzük, hogy a felhasználó követőitől származó 5 legjobb tweet megjelenik az idővonalon a létrehozási idő sorrendjében. Fenntarthatunk egy 50 tweet frissítési határt. A küszöb elérése után továbbra is leállítjuk a frissítést vagy az idővonal létrehozását, amíg a felhasználó nem frissíti az oldalt.
A magas késleltetési és teljesítményproblémák az élő felhasználói hírcsatorna létrehozásából származnak. Ehelyett egy azonnal bemutatható offline adatfolyam létrehozása a legjobb módja a teljesítmény javításának. Futtasson dedikált idővonal-kiszolgálókat, amelyek rendszeresen ping-elnek az alkalmazáskiszolgálón, hogy a hírfolyamot a létrehozásának időpontja alapján frissítsék.
A rangsorolási algoritmusnak figyelembe kell vennie a kulcsfontosságú jelzéseket, és súlyt kell adnia annak biztosítására, hogy a felhasználó idővonalát ne egy vagy több általa követett fiókból származó anyagok uralják.
Pontosabban, bármely hírfolyam-elem relevanciájához kapcsolódó funkciókat választhatunk, mint például a lájkok, megjegyzések, megosztások száma, frissítési idő. Ezen kritériumok mindegyikét kell használni a tweet értékeléséhez, majd ezt a rangot kell használni a tweetek idővonalon való megjelenítéséhez.
Folyamatosan figyelmeztetnünk kell-e a felhasználókat, ha hírfolyamukhoz új tartalom válik elérhetővé? A felhasználók hasznosnak találhatják, ha értesítést kapnak, ha új adatok válnak elérhetővé. A mobileszközökön azonban, ha az adathasználat meglehetősen költséges, sávszélességet veszíthet.
Ennek eredményeként dönthetünk úgy, hogy nem küldünk adatokat mobileszközökre, és ehelyett engedélyezhetjük a felhasználók számára a „Húzás a frissítéshez” funkciót az új bejegyzésekhez.
5. lépés: Tervezés méretezése
Egy lehetséges szűk keresztmetszet a Fanout szolgáltatás. A több millió követővel rendelkező Twitter-felhasználóknak néhány percet kell várniuk, amíg tweetjeik megjelennek. Ez versenyfutást idézhet elő a tweetre adott válaszokkal, amit elkerülhetünk, ha a tweeteket a kiszolgálás idején újrarendelik.
Azt is megakadályozhatnánk, hogy sok követővel rendelkező emberek tweetjei terjedjenek. Ehelyett megkereshetjük a gyakran követett személyek tweetjeit, integrálhatjuk a keresési eredményeket a felhasználó otthoni idővonalának eredményeivel, majd a tweeteket a kiszolgálás idején átrendezhetjük.
További fejlesztések a következők:
- Minden otthoni idővonalhoz csak néhány száz tweetet tároljon a memória-gyorsítótárban.
- A Memória-gyorsítótárban csak az aktív felhasználók otthoni idővonalának információi kerülnek mentésre.
- A kronológiát rekonstruálhatjuk az SQL-adatbázisból, ha a felhasználó nem volt aktív az előző 30 napban.
- Ha meg szeretné tudni, ki a felhasználó, használja a User Graph szolgáltatást.
- Adja hozzá a tweeteket a memória-gyorsítótárhoz úgy, hogy lekéri őket az SQL-adatbázisból.
- A Tweet Info szolgáltatás csak egy hónapnyi tweetet takaríthat meg.
- A Felhasználói információs szolgáltatásban csak az aktív felhasználók kerülnek mentésre.
- A késleltetés alacsony szinten tartásához a keresési fürtnek valószínűleg meg kell őriznie a tweeteket a memóriában.
Következtetés
Bár a Twitter egy nagy szervezet, van nála jobb is a rendszertervezés megértése. Minden tőlem telhetőt megtettem, hogy magas szintű áttekintést nyújtsak a Twitter idővonaláról.
Remélem, hasznos információkhoz jutott, és hasznosítani tudja.
Hagy egy Válaszol