Warum wir Redis verlassen und zu SolidQueue wechseln

(simplethread.com)

16 Punkte von GN⁺ 2026-01-15 | Noch keine Kommentare. | Auf WhatsApp teilen

Rails 8 entfernt die Redis-Abhängigkeit aus dem Standard-Stack und stellt mit SolidQueue, SolidCache und SolidCable alle Aufgaben auf relationale Datenbanken (RDB) um
Redis ist schnell und zuverlässig, verursacht aber operative Komplexität bei Konfiguration, Sicherheit, Cluster-Verwaltung und Backups
SolidQueue nutzt die PostgreSQL-Funktion FOR UPDATE SKIP LOCKED, um parallele Verarbeitung ohne Konkurrenz zu ermöglichen
Wiederkehrende Jobs, Concurrency Control, Monitoring-Dashboard (Mission Control) und andere kostenpflichtige Funktionen aus dem Redis+Sidekiq-Umfeld werden kostenlos bereitgestellt
Für die meisten Rails-Anwendungen reicht SolidQueue aus; nur in einigen Fällen mit extrem hoher Geschwindigkeit oder Echtzeitverarbeitung sollte Redis beibehalten werden

Die versteckten Kosten von Redis

Neben den reinen Hosting-Kosten bringt Redis laufenden Verwaltungsaufwand mit sich, etwa für Installation, Wartung, Sicherheitskonfiguration und HA-Cluster-Management
- Erforderlich sind Netzwerkverbindungen und Firewall-Konfiguration zwischen Rails und Redis, Client-Authentifizierung sowie die Orchestrierung von Sidekiq-Prozessen
Im Fehlerfall müssen Redis und das RDBMS gleichzeitig debuggt werden; zusätzlich ist eine doppelte Backup-Strategie nötig
Bei einem Rails-Stack ohne Redis muss dagegen nur ein einziges PostgreSQL-System verwaltet werden, was alles deutlich vereinfacht

Mit PostgreSQLs FOR UPDATE SKIP LOCKED holen sich mehrere Worker gleichzeitig Jobs, ohne Lock Contention zu erzeugen
Zentrale Tabellenstruktur
1. solid_queue_jobs: speichert Job-Metadaten
2. solid_queue_scheduled_executions: wartet auf geplante Jobs
3. solid_queue_ready_executions: Queue für ausführungsbereite Jobs
Worker-, Dispatcher-, Scheduler- und Supervisor-Prozesse pollen in regelmäßigen Abständen unterschiedliche Tabellen und arbeiten zusammen
Dank PostgreSQLs MVCC-Architektur und autovacuum lassen sich auch große Mengen an Insert- und Delete-Operationen stabil verarbeiten

SolidQueue bietet cron-artige wiederkehrende Jobs standardmäßig und wird über die Datei config/recurring.yml konfiguriert
Der Scheduler legt fällige Jobs in die Queue und plant den nächsten Ausführungszeitpunkt automatisch
Die Bibliothek Fugit parst natürliche Zeitpläne, und Concurrent::ScheduledTask erzeugt die Threads
Übernommen wurde der deterministische Scheduling-Ansatz von GoodJob, sodass Zeitpläne auch nach Prozessneustarts erhalten bleiben

SolidQueue unterstützt mit einem POSIX-Semaphor-Muster die Begrenzung gleichzeitiger Ausführungen pro Job-Einheit
- Beispiel: Mit limits_concurrency to: 1, key: ->(user) { user.id } wird pro Benutzer nur ein Job gleichzeitig ausgeführt
Durch das Setzen einer Semaphore-Ablaufzeit (duration) lassen sich Job-Konflikte und Deadlocks vermeiden
Zugehörige Tabellen
- solid_queue_semaphores: verfolgt Concurrency-Limits
- solid_queue_blocked_executions: speichert wartende Jobs

Mission Control Jobs ist ein kostenloses Open-Source-Dashboard für Rails 8 und lässt sich einfach unter dem Pfad /jobs mounten
Wichtige Funktionen
- Echtzeitstatus der Queues, Nachverfolgung fehlgeschlagener Jobs sowie Steuerung von Retry/Discard
- Visualisierung von Zeitachsen für geplante und wiederkehrende Jobs
- Durchsatz- und Metrikdiagramme pro Queue
Da Abfragen auf SQL basieren, ist direkte Analyse in der Datenbank ohne zusätzliche Tools möglich

Schritt 1: config.active_job.queue_adapter = :solid_queue setzen
Schritt 2: bundle add solid_queue ausführen, danach rails solid_queue:install und db:migrate
Schritt 3: Cron-Schedules aus sidekiq.yml nach recurring.yml übertragen
Schritt 4: In der Procfile jobs: bundle exec rake solid_queue:start ergänzen
Schritt 5: Redis- und Sidekiq-bezogene Gems entfernen
Vorhandener ActiveJob-Code funktioniert unverändert weiter

Dauerhafte Verarbeitung von mehreren tausend Jobs pro Sekunde
Echtzeitsysteme, bei denen Latenz unter 1 ms zwingend erforderlich ist
Bedarf an komplexen Pub/Sub-Strukturen oder ausgefeiltem Rate Limiting bzw. Counter-Operationen
Als Beispiel betreibt Shopify 833 Requests pro Sekunde und 1.172 Worker-Prozesse und nutzt dafür eine Redis-Infrastruktur

Beim Erstellen einer neuen Rails-8-App werden SolidQueue, SolidCache und SolidCable automatisch konfiguriert
In config/database.yml wird eine separate Queue-Datenbankverbindung empfohlen
Authentifizierung für Mission Control hinzufügen und die Route /jobs mounten
Procfile.dev um jobs: bundle exec rake solid_queue:start ergänzen und dann alles mit bin/dev starten
Nach dem Erzeugen von Test-Jobs lässt sich ihr Status in Mission Control prüfen

Auch eine Single-Database-Konfiguration ist möglich, reduziert aber die betriebliche Flexibilität
In Mission Control in Produktion sollte unbedingt Authentifizierung aktiviert werden
Die Standardwerte für das Polling-Intervall – 1 Sekunde für geplante Jobs, 0,2 Sekunden für sofortige Jobs – passen für die meisten Anwendungen
Bei Nutzung von ActionCable/Turbo Streams sollte SolidCable mit einer separaten Datenbankverbindung konfiguriert werden

SolidQueue skaliert für die meisten Rails-Anwendungen ausreichend
Auf PostgreSQL-Basis sind 200 bis 300 Jobs pro Sekunde möglich, und 37signals verarbeitet 20 Millionen Jobs pro Tag ohne Redis

Vergleichstabelle

Redis und Sidekiq sind hervorragende Technologien, verursachen aber für die meisten Rails-Anwendungen unnötige Komplexität und zusätzliche Kosten
SolidQueue ermöglicht auf Basis einer einzigen Datenbank einfacheren Betrieb, geringere Kosten und effizientere Wartung
Für das Rails-8-Zeitalter wird der Umstieg auf SolidQueue als Standardwahl empfohlen