Grootschalige online toepassingen hebben de afgelopen twee decennia een lange weg afgelegd. Deze innovaties hebben onze perceptie van softwareontwikkeling veranderd. Facebook, Instagram en Twitter zijn bijvoorbeeld allemaal schaalbare platforms.
Deze systemen moeten worden gebouwd om enorme hoeveelheden verkeer en gegevens te beheren, aangezien miljarden mensen ze over de hele wereld tegelijkertijd gebruiken. Dit is wanneer systeem ontwerp komt in beeld.
Het proces van het tot stand brengen van de architectuur, interfaces en gegevens voor een systeem dat aan bepaalde criteria voldoet, staat bekend als systeemontwerp. Door samenhangende en efficiënte systemen voldoet het systeemontwerp aan de eisen van uw bedrijf of organisatie.
Zodra uw bedrijf of organisatie de criteria heeft bepaald, kunt u deze gaan verwerken in een fysiek systeemontwerp dat voldoet aan de eisen van uw consumenten.
Of u nu kiest voor ontwikkeling op maat, commerciële oplossingen of een combinatie van beide, hoe u uw systeem ontwerpt, bepaalt hoe u het bouwt.
We zullen het systeemontwerp van de Twitter-tijdlijn in dit bericht gedetailleerd bekijken, compleet met een zelfstudie. Laten we beginnen.
Stap 1: Gebruiksscenario en beperkingen schetsen
Gebruik geval
- Een gebruiker uploadt een tweet.
- De dienst stuurt pushmeldingen en e-mails naar volgers van tweets.
- De tijdlijn van de gebruiker wordt bekeken (activiteit van de gebruiker)
- De gebruiker kijkt naar de tijdlijn van het huis (activiteit van mensen die de gebruiker volgt)
- Trefwoorden worden door de gebruiker gezocht.
- De service is echt toegankelijk.
Buiten bereik
- Tweets worden verzonden naar de Twitter Firehose en andere streams die deze service gebruiken.
- De dienst verwijdert tweets op basis van de zichtbaarheidsinstellingen van de gebruiker.
- Als de gebruiker de persoon op wie wordt geantwoord niet ook volgt, verbergt u het antwoord.
- Let op de optie 'retweets verbergen'.
- Analytics
Beperkingen en aannames
Aannames van de staat
- Het verkeer is niet gelijkmatig verdeeld.
- Het moet eenvoudig zijn om een tweet te versturen.
- Tenzij je miljoenen volgers hebt, zou het verzenden van een tweet naar al je volgers snel moeten gaan.
- Er zijn 100 miljoen actieve gebruikers.
- 15 miljard tweets per maand of 500 miljoen tweets per dag
- Elke tweet heeft gemiddeld een fanout van 10 bezorging.
- Fanout levert elke dag 5 miljard tweets.
- Fanout levert maandelijks 150 miljard tweets.
- 250 miljard maandelijkse leesverzoeken
- 10 miljard maandelijkse zoekopdrachten
Timeline
- De tijdlijn moet gemakkelijk te navigeren zijn.
- Twitter gaat meer over lezen dan over schrijven.
- Optimaliseren voor snel lezen van tweets
- Tweetconsumptie is tijdrovend.
Ontdek
- Het zoekproces moet snel zijn.
- Het is tijdrovend om te zoeken.
Gebruik berekenen
Grootte van elke tweet:
- 8 bytes tweet-ID
- 32 bytes gebruikers-id
- 140 bytes tekst
- media – gemiddeld 10 KB
- Totaal: ~10 KB
Elke maand wordt 150 TB aan nieuwe tweetcontent gegenereerd.
- * 500 miljoen tweets per dag * 30 dagen per maand * 10 KB per tweet
- In drie jaar tijd is er 5.4 PB aan nieuwe tweetinhoud geweest.
Er zijn 100,000 leesverzoeken per seconde.
- * (400 verzoeken per seconde / 1 miljard verzoeken per maand) 250 miljard leesverzoeken per maand
Er zijn 6,000 tweets per seconde.
- * (400 verzoeken per seconde / 1 miljard verzoeken per maand) 15 miljard tweets per maand
Op fanout worden elke seconde 60 duizend tweets verzonden.
- Fanout levert elke maand 150 miljard tweets* (400 verzoeken per seconde / 1 miljard verzoeken per maand).
4,000 verzoeken om informatie per seconde
- * (400 verzoeken per seconde / 1 miljard verzoeken per maand) 10 miljard zoekopdrachten per maand
Enkele nuttige conversie
- Elke maand gaan er 2.5 miljoen seconden voorbij.
- 2.5 miljoen verzoeken per maand bij 1 verzoek per seconde
- 100 miljoen verzoeken per maand x 40 verzoeken per seconde
- 1 miljard verzoeken per maand = 400 verzoeken per seconde
Stap 2: Diagram op hoog niveau
Stap 3: Kerncomponenten uitleggen
We zouden de eigen tweets van de gebruiker kunnen opslaan om de gebruikerstijdlijn (activiteit van de gebruiker) in een relationele database te vullen als ze een tweet indienen. Het is moeilijker om tweets te leveren en de thuistijdlijn te ontwikkelen (activiteit van personen die de gebruiker volgt).
Een typische relationele database zou worden overspoeld door tweets uit te spreiden naar alle volgers (60 duizend tweets per seconde). We willen waarschijnlijk gaan voor een snel wegschrijvende gegevensopslag zoals een NoSQL-database of geheugencache.
1 MB achtereenvolgens uit het geheugen lezen duurt ongeveer 250 microseconden, maar lezen van SSD duurt 4 keer zo lang en lezen van schijf duurt 80 keer zo lang.
Een Object Store kan worden gebruikt om gegevens zoals afbeeldingen en video's op te slaan.
- De webserver, die fungeert als een omgekeerde proxy, ontvangt een tweet van de klant.
- Het verzoek wordt door de webserver naar de Write API-server gestuurd.
- De Write API slaat de tweet op in een SQL-database in de tijdlijn van de gebruiker.
De Fan-Out Service wordt gecontacteerd door de Write API en voert de volgende taken uit.
- Vindt de volgers van de gebruiker in de geheugencache door de User Graph Service op te vragen.
- Op een Memory Cache wordt de tweet opgeslagen in de home-tijdlijn van de volgers van de gebruiker.
- 1,000 volgers = 1,000 lookups en inserts = O(n)-bewerking.
- De tweet wordt opgeslagen in de Search Index Service voor snel zoeken.
- De Object Store wordt gebruikt om media op te slaan.
- Stuurt push-alerts naar volgers via de Notification Service.
- Om waarschuwingen asynchroon te verzenden, gebruikt het een wachtrij.
We kunnen een native Redis-lijst gebruiken met de volgende structuur als onze geheugencache Redis is:
De thuistijdlijn van de gebruiker zou worden bijgewerkt met de nieuwe tweet, die zou worden opgeslagen in de geheugencache. We gebruiken de volgende openbare REST API:
De gebruikerstijdlijn wordt bekeken door de gebruiker.
- De webserver ontvangt een tijdlijnverzoek van de klant van de klant.
- Het verzoek wordt door de webserver naar de Read API-server gestuurd.
- De Read-API vraagt de SQL-database op voor het tijdsbestek van de gebruiker.
De REST API zou op dezelfde manier werken als de thuistijdlijn, met de uitzondering dat alle tweets afkomstig zouden zijn van de gebruiker in plaats van de mensen die ze volgen.
Een gebruiker zoekt op trefwoorden:
- De Web Server ontvangt een zoekopdracht van de Client.
- Het verzoek wordt door de webserver naar de Search API-server gestuurd.
Stap 4: Twitter-tijdlijn
Het maken van een tijdlijn is een moeilijke taak. Er is een tijdlijn-genererende server vereist die is gekoppeld aan het web of applicatieservers.
Elke keer dat een gebruiker zich aanmeldt, houdt de tijdlijnservice de nieuwste tweets van de gebruikers bij in de tabel van de volgers en werkt of vernieuwt de tijdlijn van de gebruiker.
We implementeren hier geen enkel soort rangschikkingssysteem; in plaats daarvan gaan we ervan uit dat de top 5 tweets van de volgers van de gebruiker in de tijdlijn worden weergegeven in volgorde van aanmaaktijd. We kunnen een verversingsgrens van 50 tweets handhaven. We stoppen nog steeds met vernieuwen of het maken van een tijdlijn nadat die drempel is bereikt, totdat de gebruiker de pagina vernieuwt.
Hoge latentie en prestatieproblemen zullen het gevolg zijn van het maken van live gebruikersfeeds. In plaats daarvan is het creëren van een offline stream die direct kan worden gepresenteerd de beste manier om de prestaties te verbeteren. Voer speciale tijdlijnservers uit die de toepassingsserver regelmatig pingen om de feed te vernieuwen op basis van het tijdstip waarop deze is gemaakt.
Het rangschikkingsalgoritme moet rekening houden met cruciale signalen en gewicht geven om te garanderen dat de tijdlijn van een gebruiker niet wordt gedomineerd door materiaal van een of meer van de accounts die ze volgen.
Om precies te zijn, kunnen we functies kiezen die verband houden met de relevantie van elk feeditem, zoals het aantal vind-ik-leuks, opmerkingen, shares en updatetijd. Elk van deze criteria moet worden gebruikt om de tweet te beoordelen, en vervolgens moet die rangorde worden gebruikt om tweets op de tijdlijn weer te geven.
Moeten we gebruikers constant waarschuwen wanneer nieuwe inhoud voor hun nieuwsfeed beschikbaar komt? Gebruikers kunnen het nuttig vinden om gewaarschuwd te worden wanneer nieuwe gegevens beschikbaar komen. Op mobiele apparaten kan het datagebruik echter behoorlijk kostbaar zijn, waardoor er bandbreedte wordt verspild.
Als gevolg hiervan kunnen we ervoor kiezen om geen gegevens naar mobiele apparaten te pushen en gebruikers in plaats daarvan toe te staan om te 'Pull to Refresh' voor nieuwe berichten.
Stap 5: ontwerp schalen
Een mogelijk knelpunt is de Fanout Service. Twitter-gebruikers met miljoenen volgers zullen enkele minuten moeten wachten voordat hun tweets zijn uitgerold. Dit kan een race veroorzaken met antwoorden op de tweet, die we zouden kunnen vermijden door de tweets opnieuw te ordenen op het moment van serveren.
Ook kunnen we voorkomen dat tweets worden verspreid van mensen met een groot aantal volgers. In plaats daarvan kunnen we zoeken naar tweets van zeer gevolgde personen, de zoekresultaten integreren met de resultaten van de thuistijdlijn van de gebruiker en de tweets opnieuw ordenen op het moment dat ze worden aangeboden.
Extra verbeteringen zijn onder meer:
- Bewaar slechts een paar honderd tweets in de geheugencache voor elke thuistijdlijn.
- In de geheugencache wordt alleen de tijdlijninformatie van actieve gebruikers opgeslagen.
- We kunnen de chronologie uit de SQL-database reconstrueren als een gebruiker de afgelopen 30 dagen niet actief was geweest.
- Gebruik de User Graph Service om erachter te komen wie de gebruiker is.
- Voeg de tweets toe aan de geheugencache door ze op te halen uit de SQL-database.
- De Tweet Info Service kan slechts een maand aan tweets opslaan.
- In de User Info Service worden alleen actieve gebruikers opgeslagen.
- Om de latentie laag te houden, zou het zoekcluster hoogstwaarschijnlijk de tweets in het geheugen moeten bewaren.
Conclusie
Hoewel Twitter een grote organisatie is, heeft het een betere begrip van systeemontwerp. Ik heb mijn best gedaan om je een overzicht op hoog niveau van de Twitter-tijdlijn te geven.
Ik hoop dat je er nuttige informatie uit hebt gehaald en er goed gebruik van kunt maken.
Laat een reactie achter