Attualmente la mia installazione di Discourse utilizza un database PostgreSQL gestito da DigitalOcean e un’istanza Redis gestita da DigitalOcean. È necessario il server Redis gestito?
Discourse memorizza qualcosa di permanente in Redis o viene utilizzato solo per la cache e altri tipi di dati temporanei?
La mia configurazione attuale (di sicuro eccessiva, ma renderà facile il ridimensionamento se necessario in futuro):
Server PostgreSQL gestito da DigitalOcean
Istanza Redis gestita da DigitalOcean
Load Balancer di DigitalOcean
Due droplet DigitalOcean, ognuno dei quali esegue Discourse
Una configurazione più semplice che stavo considerando è:
Server PostgreSQL gestito da DigitalOcean
Un singolo server che esegue sia Redis che l’applicazione Discourse, con un IP flottante per passare a un server di backup se necessario.
La mia configurazione attuale può scambiare i server web senza interruzioni e senza che l’utente se ne accorga grazie al server Redis esterno; penso che nella configurazione più semplice gli utenti verranno disconnessi se sarà necessario passare al server di backup. È questo lo svantaggio principale di avere Redis sullo stesso server di Discourse?
+1 Anche io ho la stessa domanda, mi piacerebbe davvero molto vedere se qualcuno potrebbe essere così gentile da spiegare un po’ di più su Redis e Discourse
Discourse utilizza Sidekiq, un pianificatore di job open source scritto in Ruby. Sidekiq in generale (e di default) esegue solo i job e non si occupa della pianificazione, o almeno è quanto indicano i riferimenti (magari le cose sono cambiate?); tuttavia, la mia comprensione è che la versione enterprise di Sidekiq includa la pianificazione OOTB (out of the box).
Sidekiq utilizza Redis come archivio di strutture dati in memoria ed è anch’esso scritto in Ruby. Sidekiq legge i job da una coda Redis, utilizzando il modello First In First Out (FIFO), per elaborare i job. L’elaborazione dei job è asincrona e permette a un thread web di servire richieste in tempo reale, invece di elaborare compiti pesanti che possono essere “pianificati” per essere eseguiti in background.
Sidekiq è descritto come un “software ben noto per l’elaborazione di code” ed è utilizzato da Discourse per job progettati per essere eseguiti come attività in background e non direttamente nelle richieste dell’applicazione web.
Puoi esplorare i molti tipi di job eseguiti da Discourse, basandoti sulla breve panoramica sopra, nel repository di Discourse:
Redis può essere utilizzato da Discourse in altre parti dell’architettura; ma, per quanto mi viene in mente, l’uso principale di Redis è come “compagno” di Sidekiq, il “tizio dei job”. I membri del team di Discourse più esperti di me sull’HLA di Discourse possono certamente fornire maggiori dettagli su come Redis viene utilizzato all’interno dell’HLA di Discourse.
Questo è un post un po’ datato, ma ho pensato di ampliare questa risposta dato che mi sono imbattuto in questa questione mentre cercavo altre informazioni su Discourse e Redis.
Ecco una risposta di un membro del team su cosa altro oltre a Sidekiq usa Discourse per Redis:
Ciao @Francis, qual è stata la tua stima di fatturazione per tutti quei servizi DigitalOcean? Sono solo curioso perché ho intenzione di installare lo stesso servizio su Google Cloud (200$ gratis). Il prezzo del servizio Discourse SaaS è fuori dal mio budget.
