Wofür verwendet Discourse Redis?

Aktuell nutzt meine Discourse-Installation eine von DigitalOcean verwaltete PostgreSQL-Datenbank und eine von DigitalOcean verwaltete Redis-Instanz. Ist der verwaltete Redis-Server notwendig?

Speichert Discourse etwas Permanentes in Redis, oder wird Redis nur für Caching oder andere Arten von temporären Daten verwendet?

Mein aktueller Setup (definitiv übertrieben, aber er erleichtert das Skalieren, falls dies eines Tages erforderlich ist):

  • Von DigitalOcean verwalteter PostgreSQL-Server
  • Von DigitalOcean verwaltete Redis-Instanz
  • DigitalOcean Load Balancer
  • Zwei DigitalOcean-Droplets, auf denen jeweils Discourse läuft

Ein einfacheres Setup, das ich in Betracht ziehe, wäre:

  • Von DigitalOcean verwalteter PostgreSQL-Server
  • Ein einzelner Server, auf dem sowohl Redis als auch die Discourse-Anwendung laufen, mit einer Floating IP, um im Notfall auf einen Backup-Server auszuweichen.

Mein aktueller Setup kann Webserver nahtlos austauschen, ohne dass der Nutzer etwas bemerkt, dank des externen Redis-Servers. Ich denke, beim einfacheren Setup würden Benutzer ausgeloggt, wenn der Backup-Server benötigt wird. Ist dies der Hauptnachteil, wenn Redis auf demselben Server wie Discourse läuft?

Vielen Dank,
Francis

7 „Gefällt mir“

+1 Ich habe die gleiche Frage. Ich würde mich sehr freuen, wenn jemand so freundlich wäre, ein bisschen mehr über Redis und Discourse zu erklären :kissing_smiling_eyes:

Discourse nutzt Sidekiq, einen Open-Source-Job-Scheduler, der in Ruby geschrieben ist. Sidekiq führt in der Regel (und standardmäßig) nur Jobs aus und übernimmt nicht die Planung – zumindest steht das in den Referenzen (vielleicht hat sich das geändert); meines Wissens ist jedoch, dass die Enterprise-Version von Sidekiq die Planung out-of-the-box mitbringt.

Sidekiq verwendet Redis als In-Memory-Datenstruktur-Speicher und ist ebenfalls in Ruby geschrieben. Sidekiq liest Jobs aus einer Redis-Warteschlange im First-In-First-Out-(FIFO)-Modell aus, um sie zu verarbeiten. Die Jobverarbeitung erfolgt asynchron und ermöglicht es einem Web-Thread, Live-Anfragen zu bedienen, anstatt rechenintensive Aufgaben zu bearbeiten, die als Hintergrundjobs „geplant

9 „Gefällt mir“

Das ist ein etwas veraltetes Thema, aber ich dachte, ich sollte diese Antwort ergänzen, da ich beim Suchen nach anderen Discourse-Redis-Themen auf dieses gestoßen bin.

Hier ist eine Antwort eines Teammitglieds zu der Frage, wofür Discourse neben Sidekiq noch Redis verwendet:

5 „Gefällt mir“

Hallo @Francis, was war deine geschätzte Abrechnung für all diese DigitalOcean-Dienste? Ich bin nur neugierig, weil ich plane, denselben Dienst in der Google Cloud zu installieren (200 $ kostenlos). Der Preis für den Discourse-SAS-Dienst übersteigt mein Budget.

Eine wilde Vermutung ist, dass ein Load Balancer, Redis und Postgres 50 $/Monat kosten, zuzüglich dessen, was Sie für den/die Droplet(s) bezahlen.

Wenn Sie sich Sorgen um die Kosten machen, empfehle ich einen 2-GB-Droplet und verdoppeln Sie ihn, wenn er nicht ausreicht.