Velké online aplikace ušly v předchozích dvou desetiletích dlouhou cestu. Tyto inovace změnily naše vnímání vývoje softwaru. Facebook, Instagram a Twitter, například, jsou všechny škálovatelné platformy.
Tyto systémy musí být postaveny tak, aby zvládaly obrovské objemy provozu a dat, protože je současně používají miliardy lidí po celém světě. To je když návrh systému vstoupí do obrázku.
Proces vytváření architektury, rozhraní a dat pro systém, který splňuje určitá kritéria, se nazývá návrh systému. Prostřednictvím soudržných a efektivních systémů uspokojí návrh systému požadavky vašeho podnikání nebo organizace.
Jakmile vaše společnost nebo organizace určí svá kritéria, můžete je začít začleňovat do fyzického návrhu systému, který splňuje požadavky vašich spotřebitelů.
Ať už se rozhodnete pro zakázkový vývoj, komerční řešení nebo kombinaci těchto dvou, způsob, jakým svůj systém navrhnete, určí, jak jej postavíte.
V tomto příspěvku se podrobně podíváme na systémový design časové osy Twitteru, doplněný o tutoriál. Začněme.
Krok 1: Nastíněte případ použití a omezení
Případ použití
- Uživatel nahraje tweet.
- Služba zasílá push notifikace a e-maily sledujícím tweety.
- Je zobrazena časová osa uživatele (aktivita od uživatele)
- Uživatel se podívá na domovskou časovou osu (aktivita lidí, které uživatel sleduje)
- Klíčová slova vyhledává uživatel.
- Služba je opravdu dostupná.
Mimo rozsah
- Tweety jsou odesílány do Twitter Firehose a dalších streamů pomocí této služby.
- Služba odstraňuje tweety na základě nastavení viditelnosti uživatele.
- Pokud uživatel také nesleduje osobu, na kterou se odpovídá, skryjte odpověď.
- Sledujte možnost „skrýt retweety“.
- Analýza
Omezení a předpoklady
Předpoklady stavu
- Provoz není rovnoměrně rozptýlen.
- Odeslání tweetu by mělo být jednoduché.
- Pokud nemáte miliony sledujících, odeslání tweetu všem vašim sledujícím by mělo být rychlé.
- Aktivních uživatelů je 100 milionů.
- 15 miliard tweetů každý měsíc nebo 500 milionů tweetů každý den
- Každý tweet má průměrně 10 zobrazení.
- Každý den fanout doručí 5 miliard tweetů.
- Fanout každý měsíc dodá 150 miliard tweetů.
- 250 miliard žádostí o čtení měsíčně
- 10 miliard vyhledávání měsíčně
Timeline
- Časová osa by měla být snadno ovladatelná.
- Twitter je více o čtení než psaní.
- Optimalizujte pro rychlé čtení tweetů
- Spotřeba tweetů je časově náročná.
Vyhledávání
- Proces vyhledávání by měl být rychlý.
- Hledání je časově náročné.
Spočítejte využití
Velikost každého tweetu:
- 8bajtové ID tweetu
- 32 bajtů ID uživatele
- 140 bajtů textu
- média – průměrně 10 KB
- Celkem: ~10 kB
Každý měsíc se vygeneruje 150 TB nového obsahu tweetů.
- * 500 milionů tweetů každý den * 30 dní v měsíci * 10 KB na tweet
- Za tři roky bylo 5.4 PB čerstvého obsahu tweetů.
Každou sekundu je 100,000 XNUMX požadavků na čtení.
- * (400 požadavků za sekundu / 1 miliarda požadavků za měsíc) 250 miliard požadavků na čtení každý měsíc
Každou sekundu je 6,000 XNUMX tweetů.
- * (400 požadavků za sekundu / 1 miliarda požadavků za měsíc) 15 miliard tweetů každý měsíc
Na fanout se každou sekundu odešle 60 tisíc tweetů.
- Fanout dodá 150 miliard tweetů každý měsíc* (400 požadavků za sekundu / 1 miliarda požadavků za měsíc).
4,000 žádostí o informace každou sekundu
- * (400 požadavků za sekundu / 1 miliarda požadavků za měsíc) 10 miliard vyhledávání každý měsíc
Nějaká užitečná konverze
- Každý měsíc uplyne 2.5 milionu sekund.
- 2.5 milionu požadavků za měsíc při 1 požadavku za sekundu
- 100 milionů požadavků za měsíc x 40 požadavků za sekundu
- 1 miliarda požadavků za měsíc = 400 požadavků za sekundu
Krok 2: Diagram na vysoké úrovni
Krok 3: Vysvětlení základních komponent
Mohli bychom uložit vlastní tweety uživatele, abychom naplnili časovou osu uživatele (aktivitu od uživatele) v relační databázi, pokud odešle tweet. Je obtížnější doručovat tweety a rozvíjet domovskou časovou osu (aktivita jednotlivců, které uživatel sleduje).
Typická relační databáze by byla zahlcena rozdáváním tweetů všem sledujícím (60 tisíc tweetů doručených každou sekundu). Pravděpodobně budeme chtít použít úložiště dat s rychlým zápisem, jako je databáze NoSQL nebo Memory Cache.
Postupné čtení 1 MB z paměti trvá zhruba 250 mikrosekund, ale čtení z SSD trvá 4krát déle a čtení z disku 80krát déle.
Úložiště objektů lze použít k ukládání dat, jako jsou obrázky a videa.
- Webový server, který funguje jako reverzní proxy, obdrží tweet od klienta.
- Webový server odešle požadavek na server API pro zápis.
- Write API uloží tweet do databáze SQL na časové ose uživatele.
Služba Fan-Out je kontaktována rozhraním Write API a provádí následující úkoly.
- Vyhledá sledující uživatele v mezipaměti pomocí dotazu na službu User Graph Service.
- V mezipaměti se tweet uloží na domovskou časovou osu sledujících uživatele.
- 1,000 1,000 sledujících = XNUMX XNUMX vyhledávání a vložení = operace O(n).
- Tweet je uložen ve službě Search Index Service pro rychlé vyhledávání.
- Úložiště objektů slouží k ukládání médií.
- Odesílá upozornění push sledujícím prostřednictvím služby oznámení.
- K asynchronnímu odesílání výstrah používá frontu.
Pokud je naše mezipaměť Redis, můžeme použít nativní seznam Redis s následující strukturou:
Domovská časová osa uživatele by byla aktualizována novým tweetem, který by byl uložen v mezipaměti. Využijeme následující veřejné REST API:
Uživatel si prohlíží časovou osu uživatele.
- Webový server obdrží od klienta požadavek na časovou osu uživatele.
- Webový server odešle požadavek na server Read API.
- Rozhraní API pro čtení se dotazuje databáze SQL na časový rámec uživatele.
REST API by fungovalo podobně jako domovská časová osa, s tou výjimkou, že všechny tweety by pocházely od uživatele, nikoli od lidí, které sledují.
Uživatel hledá klíčová slova:
- Webový server obdrží od klienta požadavek na vyhledávání.
- Webový server odešle požadavek na vyhledávací server API.
Krok 4: Časová osa Twitteru
Vytvoření časové osy je obtížný úkol. Je vyžadován server generující časovou osu, který se propojuje s webovými nebo aplikačními servery.
Pokaždé, když se uživatel přihlásí, služba časové osy sleduje nejnovější tweety od uživatelů v tabulce sledujících a aktualizuje nebo obnovuje časovou osu uživatele.
Neimplementujeme zde žádný systém hodnocení; místo toho předpokládáme, že prvních 5 tweetů od sledujících uživatele je uvedeno na časové ose v pořadí podle času vytvoření. Můžeme zachovat omezení obnovení 50 tweetů. Po dosažení tohoto prahu stále přestáváme obnovovat nebo vytvářet časovou osu, dokud uživatel stránku neobnoví.
Problémy s vysokou latencí a výkonem budou pocházet z vytváření živého uživatelského kanálu. Místo toho je nejlepším způsobem, jak zlepšit výkon, vytvoření offline streamu, který lze prezentovat okamžitě. Spouštějte vyhrazené servery časové osy, které pravidelně pingují aplikační server, aby obnovily zdroj podle času, kdy byl vytvořen.
Algoritmus hodnocení by měl vzít v úvahu zásadní signály a poskytnout váhu, která zaručí, že na časové ose uživatele nedominuje materiál z jednoho nebo více účtů, které sledují.
Přesněji řečeno, můžeme si vybrat funkce související s relevanci jakékoli položky zdroje, jako je počet lajků, komentářů, sdílení a čas aktualizace. Každé z těchto kritérií by mělo být použito k hodnocení tweetu a poté by toto hodnocení mělo být použito k zobrazení tweetů na časové ose.
Měli bychom neustále upozorňovat uživatele, když bude k dispozici nový obsah pro jejich newsfeed? Uživatelé mohou považovat za užitečné být upozorněni, když budou k dispozici nová data. Na mobilních zařízeních, kdy je používání dat poměrně nákladné, může plýtvat šířkou pásma.
V důsledku toho se můžeme rozhodnout neposílat data do mobilních zařízení a místo toho umožnit uživatelům „Vytažením k obnovení“ pro nové příspěvky.
Krok 5: Návrh měřítka
Potenciálním úzkým hrdlem je služba Fanout. Uživatelé Twitteru s miliony sledujících budou muset několik minut počkat, než se jejich tweety objeví. To by mohlo způsobit závod s odpověďmi na tweet, kterému bychom se mohli vyhnout přeuspořádáním tweetů v době poskytování.
Mohli bychom také zabránit šíření tweetů od lidí s velkým počtem sledujících. Místo toho můžeme provést vyhledávání tweetů od vysoce sledovaných jednotlivců, integrovat výsledky vyhledávání s výsledky domovské časové osy uživatele a poté změnit pořadí tweetů v době poskytování.
Mezi další vylepšení patří:
- Uchovávejte pouze několik stovek tweetů v mezipaměti pro každou domovskou časovou osu.
- V mezipaměti se ukládají pouze informace o domovské časové ose aktivních uživatelů.
- Můžeme rekonstruovat chronologii z SQL databáze, pokud uživatel nebyl aktivní v předchozích 30 dnech.
- Chcete-li zjistit, kdo je uživatel, použijte službu Graf uživatelů.
- Přidejte tweety do mezipaměti jejich načtením z databáze SQL.
- Služba Tweet Info Service dokáže uložit pouze měsíční tweety.
- Ve službě User Info Service se ukládají pouze aktivní uživatelé.
- Aby se udržela nízká latence, Search Cluster by s největší pravděpodobností musel udržovat tweety v paměti.
Proč investovat do čističky vzduchu?
Přestože je Twitter velká organizace, má lepší pochopení návrhu systému. Udělal jsem, co bylo v mých silách, abych vám poskytl přehled o časové ose Twitteru na vysoké úrovni.
Doufám, že jste z něj získali užitečné informace a dokážete je dobře využít.
Napsat komentář