Dragonfly als Drop-in-Redis-Alternative einordnen

1. Ausgangslage: warum überhaupt neue Redis-Alternativen entstehen

Redis' Architektur stammt aus einer Zeit, in der Server üblicherweise über deutlich weniger CPU-Kerne verfügten als heute üblich. Das Single-Threaded-Modell war damals eine bewusste, sinnvolle Vereinfachung, stößt aber auf modernen Servern mit 32 oder mehr Kernen an eine strukturelle Grenze, da ein einzelner Redis-Prozess niemals mehr als einen Kern für die Befehlsverarbeitung ausnutzen kann, unabhängig davon, wie viele weitere Kerne ungenutzt bleiben.

Dragonfly wurde von ehemaligen Google- und AWS-Ingenieuren als komplette Neuentwicklung konzipiert, die von Grund auf für moderne Multi-Core-Hardware und Cloud-Umgebungen ausgelegt ist, statt wie KeyDB als Fork der bestehenden Redis-Codebasis auf Multi-Threading nachgerüstet zu werden. Dieser fundamentale Unterschied im Ausgangspunkt erlaubt Architekturentscheidungen, die bei einem Fork kaum möglich gewesen wären.

2. Dragonflys Architektur: Shared-Nothing-Multi-Threading pro Kern

Statt gemeinsamer Datenstrukturen, die über Locks zwischen Threads koordiniert werden müssten, weist Dragonfly jedem verfügbaren CPU-Kern eine eigene Shard-Instanz des Datensatzes zu, die vollständig unabhängig von den anderen Shards arbeitet. Jeder Schlüssel wird deterministisch genau einem Shard zugeordnet, und ein Kern verarbeitet ausschließlich die Befehle, die seinen eigenen Shard betreffen, ohne dass dafür klassische Mutex-Locks zwischen Threads nötig wären.

Dieses Shared-Nothing-Prinzip stammt konzeptionell aus verteilten Systemen und wird hier innerhalb einer einzelnen Maschine angewendet: Statt vieler Threads, die um dieselben Datenstrukturen konkurrieren, arbeiten mehrere weitgehend unabhängige Verarbeitungseinheiten parallel, koordiniert nur dort, wo ein Befehl tatsächlich mehrere Shards gleichzeitig betrifft, etwa bei bestimmten Multi-Key-Operationen.

3. Andere Speicherstruktur: die Dashtable statt klassischer Hashtable

Für die eigentliche Schlüssel-Wert-Speicherung verwendet Dragonfly eine selbst entwickelte Datenstruktur namens Dashtable, die auf akademischer Forschung zu skalierbaren Hashtabellen aufbaut und speziell für gute Cache-Lokalität sowie geringen Speicher-Overhead pro Eintrag optimiert ist. Im Gegensatz zu Redis' klassischer Hashtable-Implementierung mit Chaining bei Kollisionen nutzt die Dashtable ein Open-Addressing-Verfahren mit mehreren Segmenten, die sich unabhängig voneinander vergrößern lassen.

Ein praktischer Effekt dieser Struktur ist ein spürbar geringerer Speicher-Overhead pro gespeichertem Schlüssel gegenüber Redis, was sich besonders bei sehr vielen kleinen Werten, wie sie in Magento-Sessions oder Fragment-Caches häufig vorkommen, in einer insgesamt kleineren Speicherbelegung niederschlägt, bei gleichzeitig vergleichbarer oder besserer Zugriffsgeschwindigkeit.

4. Snapshot-Performance: Point-in-time-Sicherung ohne klassischen Fork

Redis erstellt RDB-Snapshots klassisch über einen fork()-Systemaufruf, der den kompletten Prozessspeicher per Copy-on-Write dupliziert, was bei sehr großen Datensätzen kurzzeitig zu deutlich erhöhtem Speicherverbrauch und spürbaren Latenzspitzen führen kann, wenn viele Seiten während des Snapshots gleichzeitig verändert werden. Dragonfly vermeidet diesen Fork vollständig und implementiert stattdessen eine eigene, fork-freie Point-in-Time-Snapshot-Technik direkt auf Ebene der Dashtable.

Dabei markiert Dragonfly Einträge, die sich seit Snapshot-Beginn geändert haben, gezielt selbst und schreibt konsistente Versionen weg, ohne den gesamten Adressraum des Prozesses duplizieren zu müssen. In veröffentlichten Benchmarks führt das zu einem deutlich reduzierten Speicher-Peak während des Snapshot-Vorgangs im Vergleich zu Redis' Fork-basiertem Verfahren, was besonders für speicherknapp dimensionierte Instanzen relevant ist.

# Dragonfly per Docker mit Redis-kompatiblem Port starten
docker run -d --name dragonfly \
  -p 6379:6379 \
  --ulimit memlock=-1 \
  docker.dragonflydb.io/dragonflydb/dragonfly

# Snapshot manuell anstoßen, ganz wie bei Redis gewohnt
redis-cli -p 6379 SAVE
redis-cli -p 6379 INFO memory | grep used_memory_peak

5. Kompatibilität: Redis- und Memcached-Protokoll gleichzeitig

Dragonfly implementiert das RESP-Protokoll von Redis und deckt einen sehr großen Teil des klassischen Befehlssatzes ab, von einfachen Strings über Hashes und Listen bis zu Sorted Sets, wodurch gängige Client-Bibliotheken wie phpredis ohne Codeänderung funktionieren. Zusätzlich unterstützt Dragonfly auch das Memcached-Protokoll über denselben Prozess, was für Umgebungen interessant ist, die historisch beide Systeme parallel betrieben haben.

Nicht jeder Redis-Befehl ist zum aktuellen Zeitpunkt vollständig abgedeckt, insbesondere bei sehr spezifischen administrativen Befehlen, Cluster-Modus-Feinheiten und einigen neueren Redis-Modulen, die Dragonfly bewusst nicht nachbildet. Vor einem Umstieg lohnt sich deshalb ein Abgleich der tatsächlich genutzten Befehle einer Magento-Installation gegen die von Dragonfly dokumentierte Kompatibilitätsliste.

6. Betrieb in der Praxis: Docker, Kubernetes und Speicherlimits

Dragonfly wird primär als einzelnes Container-Image ausgeliefert und ersetzt dabei bewusst die traditionelle Primär-Replik-Sentinel-Topologie durch ein vertikal skalierendes Modell: Statt viele kleine Redis-Instanzen über mehrere Kerne zu verteilen, läuft ein einzelner Dragonfly-Prozess, der durch seine Shared-Nothing-Architektur die komplette Maschine ausnutzt. Für den Betrieb auf Kubernetes bedeutet das ein einfacheres Deployment-Modell mit weniger beweglichen Teilen als ein klassisches Redis-Cluster-Setup, jedoch auch ohne die etablierten Operator-Werkzeuge, die für Redis existieren.

Beim Speicherlimit ist zu beachten, dass Dragonfly den verfügbaren Arbeitsspeicher über alle Shards hinweg gemeinsam verwaltet und intern selbst Entscheidungen über die Aufteilung trifft, während klassisches Redis pro Instanz ein festes maxmemory-Limit kennt. Für ein Magento-Setup empfiehlt sich deshalb, das Container-Speicherlimit bewusst mit ausreichend Puffer über der erwarteten Datensatzgröße zu dimensionieren und die tatsächliche Auslastung über die von Dragonfly bereitgestellten Metriken zu beobachten.

7. Benchmark-Versprechen im Vergleich zu RDB-Fork-basiertem Snapshotting

Die von Dragonfly veröffentlichten Benchmarks zeigen bei parallelen Workloads mit vielen gleichzeitigen Verbindungen einen deutlich höheren Durchsatz als bei vergleichbar dimensioniertem Redis, insbesondere auf Maschinen mit vielen Kernen, da die Shared-Nothing-Architektur nahezu linear mit der Kernanzahl skaliert, solange Multi-Key-Operationen über mehrere Shards hinweg selten bleiben.

Wichtig für die Einordnung ist, dass Herstellerbenchmarks naturgemäß unter für das eigene Produkt günstigen Bedingungen entstehen. Unabhängige Nachvollziehungen bestätigen tendenziell die grundsätzliche Richtung der Ergebnisse, insbesondere beim Snapshot-Verhalten unter Speicherdruck, empfehlen aber durchgängig eigene Lasttests mit dem tatsächlichen Zugriffsmuster der jeweiligen Anwendung, bevor Zahlen aus Marketing-Material als Entscheidungsgrundlage dienen.

8. Reifegrad-Einschätzung: Lizenz, Community und Produktionsreife

Dragonfly steht unter der Business Source License, einer Lizenz, die den Quellcode einsehbar macht und die meisten Nutzungsformen erlaubt, das Anbieten als konkurrierenden Managed-Service durch Dritte jedoch einschränkt und nach einer festgelegten Frist automatisch in eine vollständig offene Lizenz übergeht. Für den internen Betrieb in einem Magento-Shop stellt diese Lizenzform in der Praxis keine Hürde dar.

Als vergleichsweise junges Projekt fehlt Dragonfly noch die jahrzehntelange Produktionshistorie von Redis, wodurch weniger Betriebserfahrung mit seltenen Randfällen, Langzeitstabilität unter sehr unterschiedlichen Workloads und ausgereiftem Failover-Tooling vorliegt. Das dahinterstehende Unternehmen bietet inzwischen einen eigenen Managed-Service an, was zusätzlich kommerzielles Vertrauen in die eigene Produktionsreife signalisiert, ersetzt aber nicht die eigene Prüfung im konkreten Einsatzkontext.

9. Für welche Magento-Shops sich ein Test lohnt und wo Vorsicht geboten ist

Ein Testeinsatz von Dragonfly lohnt sich besonders für Shops mit sehr großem Full-Page-Cache oder Session-Datenbestand auf Maschinen mit vielen CPU-Kernen, bei denen sowohl der geringere Speicher-Overhead der Dashtable als auch die fork-freien Snapshots einen messbaren Unterschied gegenüber Redis ausmachen könnten, insbesondere wenn bisherige Redis-Snapshots regelmäßig zu spürbaren Latenzspitzen führen.

Für geschäftskritische Produktionsumgebungen mit hohen Verfügbarkeitsanforderungen empfiehlt sich dennoch zunächst ein paralleler Testbetrieb in Staging, bei dem Cluster-Modus-Feinheiten, das tatsächlich genutzte Befehlsspektrum und das Verhalten unter realistischer Last über einen längeren Zeitraum beobachtet werden, bevor Dragonfly die produktive Redis-Instanz vollständig ersetzt. Ein schrittweiser Umstieg mit klarem Rollback-Pfad bleibt die sicherere Vorgehensweise.

10. Zusammenfassung

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