Storskaliga onlineapplikationer har kommit långt under de senaste två decennierna. Dessa innovationer har förändrat vår uppfattning om mjukvaruutveckling. Facebook, Instagram och Twitter, till exempel, är alla skalbara plattformar.
Dessa system måste byggas för att hantera enorma mängder trafik och data eftersom miljarder människor använder dem samtidigt över hela världen. Det är när systemdesign går in på bilden.
Processen att etablera arkitektur, gränssnitt och data för ett system som uppfyller vissa kriterier kallas systemdesign. Genom sammanhållna och effektiva system uppfyller systemdesignen kraven från din verksamhet eller organisation.
När ditt företag eller organisation har bestämt sina kriterier kan du börja införliva dem i en fysisk systemdesign som uppfyller dina konsumenters krav.
Oavsett om du väljer att gå med skräddarsydd utveckling, kommersiella lösningar eller en kombination av de två, kommer hur du designar ditt system att avgöra hur du bygger det.
Vi kommer att ta en detaljerad titt på systemdesignen för Twitters tidslinje i det här inlägget, komplett med en handledning. Låt oss börja.
Steg 1: Beskriv användningsfall och begränsningar
Användningsfall
- En användare laddar upp en tweet.
- Tjänsten skickar push-meddelanden och e-postmeddelanden till följare av tweets.
- Användarens tidslinje visas (aktivitet från användaren)
- Användaren tittar på hemtidslinjen (aktivitet från personer som användaren följer)
- Nyckelord söks av användaren.
- Tjänsten är verkligen tillgänglig.
Ur sikte
- Tweets skickas till Twitter Firehose och andra strömmar som använder den här tjänsten.
- Tjänsten tar bort tweets baserat på användarens synlighetsinställningar.
- Om användaren inte också följer personen som besvaras, dölj svaret.
- Observera alternativet "dölj retweets".
- Analytics
Begränsningar och antaganden
Statliga antaganden
- Trafiken är inte lika fördelad.
- Det ska vara enkelt att skicka en tweet.
- Om du inte har miljontals följare borde det gå snabbt att skicka en tweet till alla dina följare.
- Det finns 100 miljoner aktiva användare.
- 15 miljarder tweets varje månad eller 500 miljoner tweets varje dag
- Varje tweet har ett fanout på 10 leveranser i genomsnitt.
- Varje dag levererar fanout 5 miljarder tweets.
- Fanout levererar 150 miljarder tweets varje månad.
- 250 miljarder månatliga läsbegäranden
- 10 miljarder sökningar per månad
tidslinje
- Tidslinjen ska vara lätt att navigera.
- Twitter handlar mer om att läsa än att skriva.
- Optimera för snabb tweetläsning
- Tweetkonsumtion är tidskrävande.
Sök
- Sökprocessen bör vara snabb.
- Det är tidskrävande att söka.
Beräkna användning
Storlek på varje tweet:
- 8 bytes tweet-id
- 32 bytes användar-id
- 140 byte text
- media – snitt 10 KB
- Totalt: ~10 kB
Varje månad genereras 150 TB färskt tweetinnehåll.
- * 500 miljoner tweets varje dag * 30 dagar per månad * 10 KB per tweet
- På tre år har det kommit 5.4 PB nytt tweetinnehåll.
Det finns 100,000 XNUMX läsbegäranden varje sekund.
- * (400 förfrågningar per sekund / 1 miljard förfrågningar per månad) 250 miljarder läsförfrågningar varje månad
Det är 6,000 XNUMX tweets varje sekund.
- * (400 förfrågningar per sekund / 1 miljard förfrågningar per månad) 15 miljarder tweets varje månad
På fanout skickas 60 tusen tweets varje sekund.
- Fanout levererar 150 miljarder tweets varje månad* (400 förfrågningar per sekund / 1 miljard förfrågningar per månad).
4,000 XNUMX förfrågningar om information varje sekund
- * (400 förfrågningar per sekund / 1 miljard förfrågningar per månad) 10 miljarder sökningar varje månad
Lite användbar konvertering
- Varje månad går 2.5 miljoner sekunder.
- 2.5 miljoner förfrågningar per månad vid 1 förfrågan per sekund
- 100 miljoner förfrågningar per månad x 40 förfrågningar per sekund
- 1 miljard förfrågningar per månad = 400 förfrågningar per sekund
Steg 2: Diagram på hög nivå
Steg 3: Förklara kärnkomponenter
Vi skulle kunna spara användarens egna tweets för att fylla i användarens tidslinje (aktivitet från användaren) i en relationsdatabas om de skickar en tweet. Det är svårare att leverera tweets och utveckla hemtidslinjen (aktivitet från individer som användaren följer).
En typisk relationsdatabas skulle bli överväldigad av att sprida tweets till alla följare (60 tusen tweets levereras varje sekund). Vi kommer förmodligen att vilja gå med en snabbskrivande datalagring som en NoSQL-databas eller Memory Cache.
Att läsa 1 MB sekventiellt från minnet tar ungefär 250 mikrosekunder, men att läsa från SSD tar 4 gånger så lång tid och läsning från disk tar 80 gånger så lång tid.
Ett objektlager kan användas för att lagra data som bilder och videor.
- Webbservern, som fungerar som en omvänd proxy, tar emot en tweet från klienten.
- Begäran skickas till Write API-servern av webbservern.
- Write API sparar tweeten i en SQL-databas på användarens tidslinje.
Fan-Out-tjänsten kontaktas av Write API, och den utför följande uppgifter.
- Hittar användarens följare i minnescachen genom att fråga efter användargraftjänsten.
- På en Memory Cache sparas tweeten i hemtidslinjen för användarens följare.
- 1,000 1,000 följare = XNUMX XNUMX uppslagningar och infogar = O(n) operation.
- Tweeten sparas i sökindextjänsten för snabb sökning.
- Objektarkivet används för att lagra media.
- Skickar push-varningar till följare via aviseringstjänsten.
- För att skicka ut varningar asynkront använder den en kö.
Vi kan använda en inbyggd Redis-lista med följande struktur om vår Memory Cache är Redis:
Användarens hemtidslinje skulle uppdateras med den nya tweeten, som skulle lagras i minnescachen. Vi kommer att använda följande offentliga REST API:
Användarens tidslinje ses av användaren.
- Webbservern tar emot en användartidslinjeförfrågan från klienten.
- Begäran skickas till Read API-servern av webbservern.
- Läs API:et frågar SQL-databasen för användarens tidsram.
REST API skulle fungera på samma sätt som hemtidslinjen, med undantaget att alla tweets kommer från användaren snarare än personerna de följer.
En användare söker efter nyckelord:
- Webbservern tar emot en sökbegäran från klienten.
- Begäran skickas till Search API-servern av webbservern.
Steg 4: Twitter tidslinje
Att skapa tidslinje är en svår uppgift. En tidslinjegenererande server som länkar till webben eller applikationsservrar krävs.
Varje gång en användare loggar in håller tidslinjetjänsten koll på de senaste tweetarna från användarna i följarens tabell och uppdaterar eller uppdaterar användarens tidslinje.
Vi implementerar inte någon form av rankningssystem här; istället förutsätter vi att de 5 bästa tweetarna från användarens följare presenteras i tidslinjen i ordning efter skapelsetid. Vi kan behålla en uppdateringsgräns på 50 tweet. Vi slutar fortfarande att uppdatera eller konstruera en tidslinje efter att tröskeln har nåtts tills användaren uppdaterar sidan.
Problem med hög latens och prestanda kommer från att skapa användarflöden live. Att skapa en offlineström som kan presenteras direkt är istället det bästa sättet att förbättra prestandan. Kör dedikerade tidslinjeservrar som pingar applikationsservern regelbundet för att uppdatera flödet baserat på när det skapades.
Rangordningsalgoritmen bör ta hänsyn till avgörande signaler och ge vikt för att garantera att en användares tidslinje inte domineras av material från ett eller flera av kontona de följer.
Närmare bestämt kan vi välja funktioner som är relaterade till relevansen av alla flödesobjekt, som antalet gilla-markeringar, kommentarer, delningar och uppdateringstid. Vart och ett av dessa kriterier ska användas för att betygsätta tweeten, och sedan ska den rangordningen användas för att visa tweets på tidslinjen.
Ska vi ständigt varna användare när nytt innehåll för deras nyhetsflöde blir tillgängligt? Användare kan tycka att det är fördelaktigt att bli varnad när ny data blir tillgänglig. På mobila enheter, men när dataanvändning är ganska kostsam, kan det slösa bandbredd.
Som ett resultat kan vi välja att inte skicka data till mobila enheter och istället tillåta användare att "dra för att uppdatera" för nya inlägg.
Steg 5: Skalningsdesign
En potentiell flaskhals är Fanout-tjänsten. Twitter-användare med miljontals följare måste vänta flera minuter på att deras tweets ska rulla ut. Detta kan orsaka ett lopp med svar på tweeten, vilket vi skulle kunna undvika genom att ordna om tweetarna vid serveringen.
Vi skulle också kunna förhindra spridning av tweets från personer med ett stort antal följare. Istället kan vi göra en sökning efter tweets från personer som följs mycket, integrera sökresultaten med användarens hemtidslinjeresultat och sedan ändra ordningen på tweetarna vid serveringstillfället.
Ytterligare förbättringar inkluderar:
- Håll bara några hundra tweets i minnescachen för varje hemtidslinje.
- I minnescachen sparas endast aktiva användares hemtidslinjeinformation.
- Vi kan rekonstruera kronologin från SQL-databasen om en användare inte hade varit aktiv under de föregående 30 dagarna.
- För att ta reda på vem användaren är, använd User Graph Service.
- Lägg till tweetarna i minnescachen genom att hämta dem från SQL-databasen.
- Tweet Info Service kan bara spara en månads tweets.
- I Användarinfotjänsten sparas endast aktiva användare.
- För att hålla latensen låg skulle sökklustret troligen behöva behålla tweets i minnet.
Slutsats
Även om Twitter är en stor organisation har den en bättre förståelse för systemdesign. Jag gjorde mitt bästa för att ge dig en översikt över Twitters tidslinje på hög nivå.
Jag hoppas att du har fått användbar information från den och kan använda den på bästa sätt.
Kommentera uppropet