KeyDB: die Multi-Threaded-Alternative zu Redis einordnen

1. Redis' Single-Threaded-Modell: Grund und Konsequenzen

Redis verarbeitet seit seiner Entstehung alle Befehle in einem einzigen Hauptthread, der über eine Event-Loop nacheinander eingehende Anfragen abarbeitet. Dieses Design vermeidet klassische Race Conditions und macht komplexe Locking-Mechanismen zwischen parallelen Threads überflüssig, da zu jedem Zeitpunkt garantiert nur ein einziger Befehl gleichzeitig auf dem Datensatz operiert, was Redis' Ruf für vorhersehbares, atomares Verhalten begründet.

Der Preis dieses Designs ist, dass ein einzelner Redis-Prozess nur einen einzigen CPU-Kern für die eigentliche Befehlsverarbeitung nutzt, selbst auf Servern mit sechzehn oder mehr Kernen. Neuere Redis-Versionen haben zwar I/O-Threads für das reine Lesen und Schreiben von Netzwerkdaten eingeführt, die eigentliche Befehlsausführung bleibt jedoch weiterhin an einen einzigen Thread gebunden, wodurch die maximale Durchsatzrate pro Instanz durch die Einzelkern-Leistung begrenzt bleibt.

2. KeyDBs Grundidee: echtes Multi-Threading für Netzwerk und Befehlsverarbeitung

KeyDB entstand als Fork von Redis mit dem expliziten Ziel, die Einzelkern-Beschränkung aufzubrechen. Statt einer einzelnen Event-Loop startet KeyDB mehrere Worker-Threads, die jeweils eigenständig Client-Verbindungen annehmen, Befehle parsen und ausführen können, wodurch mehrere CPU-Kerne parallel für die Befehlsverarbeitung genutzt werden, statt nur für Hintergrundaufgaben wie Persistenz oder Netzwerk-I/O.

Damit dieses Modell konsistent bleibt, verwendet KeyDB feingranulares Locking auf Ebene einzelner Schlüssel beziehungsweise Schlüsselbereiche, statt eines einzigen globalen Locks für den kompletten Datensatz. Zwei Threads können dadurch gleichzeitig unterschiedliche Schlüssel bearbeiten, während Operationen auf demselben Schlüssel weiterhin serialisiert ablaufen, um die von Redis-Anwendungen erwartete Atomarität einzelner Befehle zu erhalten.

3. Architektur im Detail: wie das Locking bei mehreren Threads funktioniert

Die Anzahl der genutzten Threads lässt sich über den Konfigurationsparameter server-threads steuern, wobei KeyDB empfiehlt, diesen Wert an die Anzahl der tatsächlich verfügbaren physischen CPU-Kerne anzupassen und nicht zu überdimensionieren, da zusätzliche Threads jenseits der Kernanzahl durch Kontextwechsel eher schaden als nutzen. Für Transaktionsblöcke über MULTI und EXEC sowie für Lua-Skripte über EVAL garantiert KeyDB weiterhin vollständige Atomarität, indem es während der Ausführung dieser Blöcke effektiv auf ein serialisiertes Verhalten zurückfällt.

Dieser Kompromiss bedeutet, dass Workloads mit vielen kurzen, unabhängigen Einzelbefehlen auf unterschiedlichen Schlüsseln am stärksten von der Parallelisierung profitieren, während Workloads mit vielen langen Transaktionsblöcken oder aufwendigen Lua-Skripten kaum einen Geschwindigkeitsvorteil gegenüber klassischem Redis erfahren, da die Serialisierung in diesen Fällen ohnehin greift.

# server-threads in keydb.conf an die Kernanzahl anpassen
server-threads 4
server-thread-affinity true

# Nach dem Start prüfen, wie viele Threads tatsächlich aktiv sind
keydb-cli INFO server | grep -i thread

4. Kompatibilitätsgrad zum Redis-Protokoll: Drop-in-Anspruch in der Praxis

KeyDB positioniert sich explizit als Drop-in-Replacement für Redis und implementiert dasselbe RESP-Protokoll sowie den überwiegenden Teil der Redis-Befehle mit identischer Signatur, sodass gängige Client-Bibliotheken wie phpredis ohne Codeänderung gegen KeyDB funktionieren. Auch das RDB-Format für Snapshots bleibt kompatibel, was eine bestehende Redis-Dump-Datei ohne Konvertierung direkt von KeyDB einlesbar macht.

Unterschiede zeigen sich vor allem bei sehr neuen Redis-Befehlen, die erst nach dem jeweiligen Fork-Zeitpunkt von KeyDB in Redis eingeführt wurden, sowie bei einigen internen Metriken und Konfigurationsparametern, die spezifisch für die Multi-Threading-Architektur von KeyDB sind und in Standard-Redis keine Entsprechung haben. Für den überwiegenden Teil klassischer Datenstruktur-Operationen wie Strings, Hashes, Listen und Sets bleibt die Kompatibilität jedoch hoch.

5. Benchmark-Ergebnisse und wann Multi-Core-Nutzung wirklich hilft

In von KeyDB selbst veröffentlichten Benchmarks sowie unabhängigen Nachvollziehungen zeigt sich ein deutlich höherer Durchsatz gegenüber Redis, insbesondere bei Workloads mit vielen parallelen Verbindungen und kurzen, unabhängigen Befehlen auf Maschinen mit acht oder mehr Kernen. Bei Maschinen mit wenigen Kernen oder bei Workloads, die ohnehin stark durch Netzwerklatenz statt durch CPU-Zeit begrenzt sind, fällt der gemessene Vorteil gegenüber Redis deutlich geringer aus.

Für einen typischen Magento-Shop, bei dem Redis primär als Full-Page-Cache- und Session-Backend dient, hängt der tatsächliche Nutzen stark von der Anzahl gleichzeitiger PHP-FPM-Worker ab, die parallel gegen dieselbe Redis-Instanz zugreifen. Bei kleinen bis mittleren Shops mit begrenzter Parallelität bleibt der Unterschied oft klein, während sehr traffic-starke Shops mit vielen gleichzeitigen Verbindungen von der Parallelisierung spürbar profitieren können.

6. Persistenz und Speicherverhalten bei mehreren gleichzeitig aktiven Threads

Bei der Snapshot-Erstellung über RDB verhält sich KeyDB grundsätzlich wie klassisches Redis und nutzt weiterhin einen fork()-basierten Copy-on-Write-Mechanismus, wodurch die bekannten Speicherspitzen bei sehr großen Datensätzen unverändert auftreten können. Für AOF-Persistenz gilt Ähnliches: Die Schreiblogik selbst bleibt vom Multi-Threading der Befehlsverarbeitung weitgehend unabhängig, da Persistenzoperationen ohnehin in eigenen Hintergrundprozessen beziehungsweise -threads laufen.

Ein Unterschied zeigt sich beim Speicher-Overhead pro Verbindung: Da jeder Worker-Thread eigene Puffer für eingehende und ausgehende Daten verwaltet, kann der Speicherbedarf bei sehr vielen gleichzeitigen Verbindungen gegenüber Redis leicht höher ausfallen. Für Magento-Setups mit moderater Verbindungsanzahl, etwa über einen Connection Pool von PHP-FPM, fällt dieser Effekt in der Praxis kaum ins Gewicht, sollte bei sehr großen, verbindungsintensiven Deployments jedoch im Speicher-Sizing berücksichtigt werden.

7. Aktive Multi-Master-Replikation als eigenständiges Zusatzfeature

Neben dem Multi-Threading bringt KeyDB ein zweites, unabhängiges Feature mit: aktive Multi-Master-Replikation, bei der mehrere KeyDB-Instanzen gleichzeitig Schreibvorgänge annehmen und sich gegenseitig replizieren, statt der klassischen Primär-Replik-Topologie von Redis mit genau einer schreibfähigen Instanz. Konflikte zwischen gleichzeitigen Schreibvorgängen auf verschiedenen Instanzen werden dabei nach einer Last-Write-Wins-Strategie aufgelöst.

Dieses Feature eignet sich vor allem für geografisch verteilte Setups, bei denen mehrere Standorte jeweils lokal gegen eine eigene KeyDB-Instanz schreiben sollen, ist für den klassischen Magento-Anwendungsfall mit einer zentralen Datenbank jedoch selten relevant, da Magento selbst nicht für ein Multi-Master-Cache-Backend ausgelegt ist und die Last-Write-Wins-Semantik bei Sessions zu inkonsistentem Verhalten führen könnte.

8. Risiken: Projektstatus nach der Snap-Übernahme und Wartungslage

KeyDB wurde 2022 vom Backup-Anbieter Snap Inc. übernommen, was zunächst für zusätzliche Ressourcen im Projekt sorgte. In der Folge verlangsamte sich die öffentliche Entwicklungsaktivität jedoch spürbar, und die Pflege des Projekts liegt inzwischen stärker bei der verbleibenden Community als bei einem dedizierten kommerziellen Team, was sich in längeren Reaktionszeiten auf gemeldete Probleme und selteneren Major-Releases zeigt.

Wer KeyDB produktiv einsetzt, sollte deshalb den Projektstatus, offene Sicherheitslücken und die Aktualität gegenüber neueren Redis-Versionen regelmäßig selbst beobachten, statt sich auf denselben Grad an kommerzieller Unterstützung zu verlassen, wie er bei Redis Ltd oder etablierten Managed-Services besteht. Für kritische Produktionsumgebungen ist diese Unsicherheit ein Faktor, der gegen den reinen Performance-Vorteil abgewogen werden muss.

9. Praktische Einsatzszenarien für Magento: wann sich der Umstieg lohnen könnte

Ein Umstieg auf KeyDB kann sich lohnen, wenn ein bestehender Redis-Server bei hoher Parallelität nachweislich an die CPU-Grenze eines einzelnen Kerns stößt, während weitere Kerne der Maschine ungenutzt bleiben, was sich über redis-cli INFO cpu und Systemmetriken wie top pro Kern nachvollziehen lässt. Für sehr traffic-starke Magento-Installationen mit vielen gleichzeitigen PHP-FPM-Workern kann dieser Effekt real spürbar werden.

Für die meisten kleineren und mittleren Magento-Shops bleibt der Engpass jedoch selten die CPU-Auslastung von Redis selbst, sondern eher Netzwerklatenz, Speichergröße oder die Anwendungslogik. In diesen Fällen überwiegt das zusätzliche Betriebsrisiko eines weniger etablierten Forks gegenüber dem messbaren Nutzen, weshalb ein sorgfältiger Lasttest vor jeder produktiven Umstellung unerlässlich bleibt.

10. Zusammenfassung

11. FAQ: KeyDB als Redis-Alternative: Das Wichtigste auf einen Blick