Le applicazioni online su larga scala hanno fatto molta strada negli ultimi due decenni. Queste innovazioni hanno alterato la nostra percezione dello sviluppo del software. Facebook, Instagram e Twitter, ad esempio, sono tutte piattaforme scalabili.
Questi sistemi devono essere costruiti per gestire enormi volumi di traffico e dati poiché miliardi di persone li utilizzano contemporaneamente in tutto il mondo. Questo è quando sistema di design entra nella foto.
Il processo di definizione dell'architettura, delle interfacce e dei dati per un sistema che soddisfa determinati criteri è noto come progettazione del sistema. Attraverso sistemi coesi ed efficienti, la progettazione del sistema soddisfa le esigenze della tua azienda o organizzazione.
Una volta che la tua azienda o organizzazione ha determinato i suoi criteri, puoi iniziare a incorporarli in un progetto di sistema fisico che soddisfi le esigenze dei tuoi consumatori.
Sia che tu scelga di sviluppare soluzioni commerciali, soluzioni commerciali o una combinazione dei due, il modo in cui progetti il tuo sistema determinerà come lo costruirai.
Daremo uno sguardo dettagliato al design del sistema della timeline di Twitter in questo post, completo di un tutorial. Iniziamo.
Passaggio 1: delineare casi d'uso e vincoli
Caso d'uso
- Un utente carica un tweet.
- Il servizio invia notifiche push ed e-mail ai follower dei tweet.
- Viene visualizzata la sequenza temporale dell'utente (attività dell'utente)
- L'utente guarda la sequenza temporale principale (attività delle persone che l'utente sta seguendo)
- Le parole chiave vengono ricercate dall'utente.
- Il servizio è davvero accessibile.
Fuori portata
- I tweet vengono inviati a Twitter Firehose e ad altri flussi che utilizzano questo servizio.
- Il servizio rimuove i tweet in base alle impostazioni di visibilità dell'utente.
- Se l'utente non segue anche la persona a cui ha risposto, nascondi la risposta.
- Osserva l'opzione "nascondi retweet".
- Analisi
Vincoli e ipotesi
Assunzioni di Stato
- Il traffico non è equamente disperso.
- Dovrebbe essere semplice inviare un tweet.
- A meno che tu non abbia milioni di follower, inviare un tweet a tutti i tuoi follower dovrebbe essere veloce.
- Ci sono 100 milioni di utenti attivi.
- 15 miliardi di tweet ogni mese o 500 milioni di tweet ogni giorno
- Ogni tweet ha in media un fanout di 10 consegne.
- Ogni giorno, fanout fornisce 5 miliardi di tweet.
- Fanout fornisce 150 miliardi di tweet ogni mese.
- 250 miliardi di richieste di lettura mensili
- 10 miliardi di ricerche mensili
Cronologia
- La sequenza temporale dovrebbe essere facile da navigare.
- Twitter riguarda più la lettura che la scrittura.
- Ottimizza per la lettura rapida dei tweet
- Il consumo di tweet richiede tempo.
Cerca
- Il processo di ricerca dovrebbe essere rapido.
- La ricerca richiede molto tempo.
Calcola l'utilizzo
Dimensione di ogni tweet:
- ID tweet da 8 byte
- 32 byte ID utente
- 140 byte di testo
- media – media di 10 KB
- Totale: ~10 KB
Ogni mese vengono generati 150 TB di nuovi contenuti tweet.
- * 500 milioni di tweet ogni giorno * 30 giorni al mese * 10 KB per tweet
- In tre anni, ci sono stati 5.4 PB di nuovi contenuti di tweet.
Ci sono 100,000 richieste di lettura al secondo.
- * (400 richieste al secondo / 1 miliardo di richieste al mese) 250 miliardi di richieste di lettura ogni mese
Ci sono 6,000 tweet al secondo.
- * (400 richieste al secondo / 1 miliardo di richieste al mese) 15 miliardi di tweet al mese
Al fanout vengono inviati 60mila tweet al secondo.
- Fanout fornisce 150 miliardi di tweet ogni mese* (400 richieste al secondo / 1 miliardo di richieste al mese).
4,000 richieste di informazioni al secondo
- * (400 richieste al secondo / 1 miliardo di richieste al mese) 10 miliardi di ricerche al mese
Qualche utile conversione
- Ogni mese passano 2.5 milioni di secondi.
- 2.5 milioni di richieste al mese a 1 richiesta al secondo
- 100 milioni di richieste al mese x 40 richieste al secondo
- 1 miliardo di richieste al mese = 400 richieste al secondo
Passaggio 2: diagramma di alto livello
Passaggio 3: spiegazione dei componenti principali
Potremmo salvare i tweet dell'utente per popolare la sequenza temporale dell'utente (attività dell'utente) in un database relazionale se invia un tweet. È più difficile fornire tweet e sviluppare la sequenza temporale di casa (l'attività degli individui segue l'utente).
Un tipico database relazionale verrebbe sopraffatto dalla diffusione di tweet a tutti i follower (60mila tweet consegnati ogni secondo). Probabilmente vorremo utilizzare un archivio di dati a scrittura rapida come un database NoSQL o una cache di memoria.
La lettura sequenziale di 1 MB dalla memoria richiede circa 250 microsecondi, ma la lettura da SSD richiede 4 volte di più e la lettura da disco richiede 80 volte di più.
Un Object Store può essere utilizzato per memorizzare dati come immagini e video.
- Il Web Server, che funge da proxy inverso, riceve un tweet dal Cliente.
- La richiesta viene inviata al server Write API dal Web Server.
- L'API di scrittura salva il tweet in un database SQL nella sequenza temporale dell'utente.
Il servizio Fan-Out viene contattato dall'API di scrittura ed esegue le seguenti attività.
- Trova i follower dell'utente nella cache di memoria eseguendo una query sul servizio grafico utente.
- In una Memory Cache, il tweet viene salvato nella sequenza temporale principale dei follower dell'utente.
- 1,000 follower = 1,000 ricerche e inserimenti = O(n) operazione.
- Il tweet viene salvato nel servizio Indice di ricerca per una ricerca rapida.
- Object Store viene utilizzato per memorizzare i media.
- Invia avvisi push ai follower tramite il servizio di notifica.
- Per inviare avvisi in modo asincrono, utilizza una coda.
Possiamo utilizzare un elenco Redis nativo con la seguente struttura se la nostra Memory Cache è Redis:
La cronologia principale dell'utente verrebbe aggiornata con il nuovo tweet, che verrebbe archiviato nella Memory Cache. Utilizzeremo la seguente API REST pubblica:
La sequenza temporale dell'utente viene visualizzata dall'utente.
- Il Web Server riceve una richiesta di sequenza temporale dell'utente dal Cliente.
- La richiesta viene inviata al server Read API dal Web Server.
- L'API di lettura interroga il database SQL per l'intervallo di tempo dell'utente.
L'API REST funzionerebbe in modo simile alla sequenza temporale principale, con l'eccezione che tutti i tweet provenirebbero dall'utente anziché dalle persone che seguono.
Un utente cerca parole chiave:
- Il Web Server riceve una richiesta di ricerca dal Cliente.
- La richiesta viene inviata al server dell'API di ricerca dal Web Server.
Passaggio 4: cronologia di Twitter
La creazione della sequenza temporale è un compito difficile. È necessario un server di generazione della sequenza temporale che si colleghi al Web o ai server delle applicazioni.
Ogni volta che un utente accede, il servizio di sequenza temporale tiene traccia dei tweet più recenti degli utenti nella tabella dei follower e aggiorna o aggiorna la sequenza temporale dell'utente.
Non implementiamo alcun tipo di sistema di classificazione qui; presumiamo invece che i primi 5 tweet dei follower dell'utente siano presentati nella timeline in ordine di tempo di creazione. Possiamo mantenere un limite di aggiornamento di 50 tweet. Smettiamo ancora di aggiornare o costruire una sequenza temporale dopo il raggiungimento di tale soglia fino a quando l'utente non aggiorna la pagina.
I problemi di latenza e prestazioni elevate deriveranno dalla creazione di feed utente in tempo reale. Invece, la creazione di uno streaming offline che può essere presentato all'istante è il modo migliore per migliorare le prestazioni. Esegui server della sequenza temporale dedicati che eseguono regolarmente il ping del server delle applicazioni per aggiornare il feed in base all'ora in cui è stato creato.
L'algoritmo di classificazione dovrebbe prendere in considerazione i segnali cruciali e fornire un peso per garantire che la sequenza temporale di un utente non sia dominata dal materiale di uno o più account che seguono.
Più precisamente, possiamo scegliere funzionalità relative alla pertinenza di qualsiasi elemento del feed, come il numero di Mi piace, commenti, condivisioni e tempo di aggiornamento. Ciascuno di questi criteri dovrebbe essere utilizzato per valutare il tweet, quindi quel rango dovrebbe essere utilizzato per mostrare i tweet sulla sequenza temporale.
Dovremmo avvisare costantemente gli utenti quando diventano disponibili nuovi contenuti per il loro feed di notizie? Gli utenti possono trovare utile essere avvisati quando diventano disponibili nuovi dati. Sui dispositivi mobili, tuttavia, quando l'utilizzo dei dati è piuttosto costoso, può sprecare larghezza di banda.
Di conseguenza, possiamo scegliere di non inviare i dati ai dispositivi mobili e consentire invece agli utenti di "Pull to Refresh" per i nuovi post.
Passaggio 5: ridimensionamento del design
Un potenziale collo di bottiglia è il servizio Fanout. Gli utenti di Twitter con milioni di follower dovranno attendere diversi minuti prima che i loro tweet vengano lanciati. Ciò potrebbe causare una corsa con le risposte al tweet, che potremmo evitare riordinando i tweet al momento del servizio.
Potremmo anche impedire la diffusione di tweet da persone con un numero elevato di follower. Invece, potremmo eseguire una ricerca di tweet da persone molto seguite, integrare i risultati della ricerca con i risultati della sequenza temporale principale dell'utente e quindi riordinare i tweet al momento della pubblicazione.
Ulteriori miglioramenti includono:
- Conserva solo poche centinaia di tweet nella memoria cache per ogni sequenza temporale principale.
- Nella cache di memoria vengono salvate solo le informazioni sulla sequenza temporale principale degli utenti attivi.
- Possiamo ricostruire la cronologia dal database SQL se un utente non fosse stato attivo nei 30 giorni precedenti.
- Per scoprire chi è l'utente, utilizza il servizio User Graph.
- Aggiungi i tweet alla Memory Cache recuperandoli dal database SQL.
- Il servizio informazioni sui tweet può salvare solo un mese di tweet.
- Nel Servizio informazioni utente vengono salvati solo gli utenti attivi.
- Per mantenere bassa la latenza, molto probabilmente il cluster di ricerca dovrebbe mantenere i tweet in memoria.
Conclusione
Sebbene Twitter sia una grande organizzazione, ha una migliore comprensione della progettazione del sistema. Ho fatto del mio meglio per fornirti una panoramica di alto livello della sequenza temporale di Twitter.
Spero che tu abbia ottenuto informazioni utili da esso e che tu possa farne buon uso.
Lascia un Commento