Cursori m/t disponibili verso Redis pub/sub

Question

Sto supportando un'applicazione server websocket in tempo reale con MongoDB.

La base del client è in crescita e le prestazioni single-thread non sono più sufficienti. Ho bisogno di un pub/sottolivello per distribuire i messaggi attraverso i thread.

Normalmente utilizzerei Redis, ma dato che l'app utilizza già MongoDB, è possibile evitare la dipendenza utilizzando i cursori disponibili. Tuttavia, mi preoccupo per le prestazioni.

In che modo le prestazioni del cursore di MongoDB sono paragonabili a quelle di Redis per un'architettura di pubblicazione/sub?

Answer 1

In realtà, sono animali molto diversi.

Un cursore disponibile di MongoDB funzionerebbe un po 'come una coda. Può funzionare con una collezione limitata, quindi non è necessario eliminare esplicitamente gli elementi nella raccolta. È abbastanza efficiente, ma ricorda che MongoDB bloccherà l'intera collezione (il database in effetti) ad ogni operazione di scrittura, quindi limita la scalabilità. Un altro limite di scalabilità è il numero di connessioni. Ogni connessione client aggiungerà un thread di connessione nei server mongod (o mongos).

Ancora si possono aspettare decine di migliaia di articoli al secondo senza grossi problemi, che potrebbero essere sufficienti per una vasta gamma di applicazioni.

D'altra parte, Redis può generalmente gestire molte più connessioni contemporaneamente, poiché ogni connessione non crea un thread (Redis è un loop di eventi single-theaded). È anche estremamente efficiente per la CPU, perché non fa la coda a tutti gli oggetti. Con Redis pub/sub, gli elementi vengono propagati ai sottoscrittori nella stessa iterazione del ciclo di eventi rispetto alla pubblicazione. Gli elementi non sono nemmeno memorizzati, Redis non ha nemmeno un indice singolo da mantenere. Vengono recuperati da un buffer di socket solo per essere inseriti in un altro buffer di socket.

Tuttavia, poiché non vi sono accodamenti, la consegna dei messaggi pub/sub di Redis non è garantita. Se un abbonato è inattivo quando viene pubblicato un messaggio, il messaggio verrà perso per questo utente.

Con Redis, è possibile prevedere centinaia di migliaia di articoli al secondo su un singolo core, soprattutto se si utilizza la pipeline e più client di pubblicazione.