Usiamo Redis su Trello per dati effimeri che saremmo d'accordo a perdere. Non conserviamo i dati in Redis su disco e lo usiamo allkeys-lru, quindi memorizziamo solo le cose che possono essere espulse in qualsiasi momento con solo un inconveniente molto lieve per gli utenti (ad esempio vedendo momentaneamente uno stato utente errato). Detto questo, gli diamo più di 5 volte lo spazio di cui ha bisogno per memorizzare il suo set di lavoro effettivo e scegliere tra 10 chiavi per la scadenza, quindi non vediamo mai davvero nulla che venga espulso che stiamo utilizzando.
-
È il nostro server pubsub. Quando un utente fa qualcosa su una scheda o una scheda, vogliamo inviare un messaggio con quel delta a tutti i client connessi a websocket che sono iscritti all'oggetto che è cambiato, quindi tutti i nostri processi Node sono iscritti a un canale pubsub che si propaga quei messaggi e li propagano ai websocket adeguatamente autorizzati e sottoscritti.
-
Lo usiamo in una sorta di back socket.io, ma dal momento che utilizziamo solo i websocket e poiché socket.io è troppo loquace per essere ridimensionato come ne abbiamo bisogno al momento, abbiamo una patch che disabilita tutto tranne un canale che ci è necessario.
-
Per i nostri utenti che non dispongono di websocket, dobbiamo mantenere un elenco delle azioni che sono avvenute su ciascun canale oggetto dall'ultima richiesta di sondaggio dell'utente. Per questo utilizziamo un elenco che limitiamo ai 100 elementi più recenti e un contatore ausiliario di quanti elementi sono stati aggiunti all'elenco da quando è stato creato. Quindi, quando rispondiamo a una richiesta di sondaggio da un tale browser, possiamo controllare l'ultimo elemento che segnala di aver visto e inviare solo i messaggi che sono stati aggiunti alla coda da allora. In questo modo, nella maggior parte dei casi, una richiesta di sondaggio si riduce solo a un controllo delle autorizzazioni e un singolo controllo della chiave Redis, il che è molto veloce.
-
Archiviamo alcuni dati effimeri sullo stato attivo degli utenti connessi in Redis, perché tali dati cambiano frequentemente e non è necessario mantenerli su disco.
-
Archiviamo chiavi di breve durata per supportare gli accessi OAuth in Redis.
Amiamo Redis; una volta che ne hai un'istanza attiva e funzionante, vuoi usarla per tutti i tipi di cose. L'unico vero problema che abbiamo avuto con esso è stato con i clienti che consumano lentamente consumando lo spazio disponibile.
Usiamo MongoDB per le nostre esigenze di database più tradizionali.
