Valkey baut ueber Caching hinaus: Maintainerrate erzaehlen von Roadmap und Cluster-Fortschritten
Der vor gut zwei Jahren als Redis-Fork gestartete das Valkey-Projekt wird von zwoelf Maintainern und neun Komitee-Mitgliedern verschiedener Firmen getragen. Zu den Entwicklungen zaehlen hoeherer Durchsatz und ein verbessertes Clustering, geplant sind unter anderem synchrone Replikation und weitere Features.
InfoQ: Danke, dass Sie sich die Zeit nehmen, einige Fragen für unsere Leser zu beantworten. Stellen Sie sich doch zunächst einmal vor.
Olson: Ich bin Madelyn Olson, und ich habe bei der Erstellung des Forks nach der Lizenzänderung mitgeholfen. Ich arbeite bei AWS und bin Mitglied im technischen Lenkungsausschuss (TSC) von Valkey. Vor Valkey war ich auch bereits Redis Committer.
Söderqvist: Ich bin Viktor Söderqvist, arbeite bei Ericsson im Bereich Open Source und war ebenfalls an der Erstellung des Forks beteiligt.
InfoQ: Was haben die Releases 8.x technisch verändert?
Olson: Das Thema war grundlegende Infrastruktur. Async I/O Threading erhöhte den Durchsatz von etwa 200.000 bis 250.000 Anfragen pro Sekunde auf rund eine Million pro Prozess. Anders als bei der bisherigen Anordnung der I/O-Threads lässt sich die Thread-Konfiguration zur Laufzeit ändern, sodass Betreiber weitere Kerne hinzufügen können, um Lastspitzen zu bewältigen. Die Versionen 8.0 und 8.1 enthielten ausserdem Arbeiten zur Speichereffizienz, etwa Key Embedding und das per-slot dictionary.
Die Dual-Channel-Replikation befasste sich mit der Belastung eines Primärknotens während der Synchronisation von Replikas. Bisher wurden eine vollständige Kopie des Datensatzes und der anschliessende Strom von Replikationsänderungen nacheinander übertragen. Der parallele Versand reduziert den Speicherdruck, der mit diesem Vorgang verbunden war.
InfoQ: Warum waren die Cluster-Änderungen in Version 9 wichtig?
Olson: Der Cluster-Modus verteilt Schlüssel nach Slots auf die Knoten, aber der Wechsel dorthin hatte zwei wesentliche Einschränkungen. Operationen über mehrere Slots hinweg erfordern, dass die Daten auf demselben Shard liegen, und der Cluster-Modus unterstützte zuvor keine nummerierten Datenbanken, also die Namensräume, die bei Einzelinstanz-Deployments verfügbar sind. Die Einführung nummerierter Datenbanken beseitigte einen Grund, aus dem manche Nutzer nicht in den Cluster-Modus migrieren konnten.
Die atomare Slot-Migration behebt ein weiteres Problem: Der schlüsselweise Transfer von Daten konnte bei einem Fehlschlag des Vorgangs einen Cluster in einem teilweise migrierten Zustand zurücklassen. Der neue Ansatz stellt die Daten zunächst bereit und schaltet dann um, sodass die Migration entweder vollständig greift oder gar nicht. Version 9 führte ausserdem den Hash-Field-Expiration-Mechanismus ein, der als eine der am häufigsten gewünschten Funktionen des Projekts gilt. Die Interviewten verwiesen auf Deployments im Stil von Mastodon, bei denen mehrere Server einen Cluster nutzen, als Beispiel für die Nachfrage nach den Cluster-Änderungen, warnten jedoch davor, dieses Arrangement als echte Multi-Tenancy zu betrachten.
InfoQ: Welches Problem soll die Client-Bibliothek GLIDE lösen?
Olson und Söderqvist: Redis-Clients hatten ursprünglich eine relativ einfache Aufgabe: die Kommunikation mit einem einzelnen Knoten. Cluster-Topologie, TLS, Redirects, Wiederverbindungen und Connection Pooling machten das Verhalten der Clients komplexer, und die verschiedenen Sprach-Clients implementierten diese Funktionen uneinheitlich. Glide, das als AWS-Projekt begann, verlagert die Verwaltung von Verbindungen und Topologie in einen gemeinsamen Rust-Kern und stellt sie über sprachspezifische Bindings bereit. Ein im Kern behobener Fehler lässt sich dadurch für alle Bindings beheben, die ihn nutzen.
WebAssembly wurde in Betracht gezogen, aber das Team hielt diesen Ansatz zum damaligen Zeitpunkt für noch zu früh. Glide soll die nativen Alternativen nicht ersetzen: Valkey unterstützt weiterhin andere Clients, darunter Go-Implementierungen, für Nutzer, deren Anforderungen bereits von diesen abgedeckt werden.
InfoQ: Was könnte Valkey über seine derzeitigen Caching-Anwendungsfälle hinausführen?
Olson und Söderqvist: Eine vorgeschlagene Richtung ist die synchrone Replikation mit dem Ziel, Dauerhaftigkeitsgarantien für Daten zu bieten, die nicht nur flüchtig sind. Ein weiterer Ansatz ist Tiering: Heisse Daten bleiben im Speicher, während kältere Daten auf SSD oder anderen Speicher ausgelagert werden.
Olson: Für Tiering könnte mehr als eine Strategie nötig sein. Kleine, selten abgerufene Schlüssel könnten aus dem DRAM ausgelagert werden; ausreichend grosse Objekte könnten stattdessen auf der Festplatte verbleiben und direkt ins Netzwerk gestreamt werden. Das Team erwägt eine allgemeinere Schnittstelle, die auch Backends über lokales NVMe hinaus unterstützen könnte, etwa S3 oder Postgres. Parquet wurde als möglicherweise nützlich für die Ausgabe von Change-Data-Capture- oder Clickstream-Daten diskutiert, nicht aber als Format zum dynamischen Lesen und Neuschreiben von gestuften Daten. Aktive-Aktiv-Replikation über Cluster hinweg mit eventual consistency bleibt eine längerfristige Idee, keine implementierte Zusage.
Neben Funktionen investiert das Projekt auch in Release- und Sicherheitsarbeiten. Automatisiertes Backporting soll die Zeit verkürzen, die benötigt wird, um Fixes über mehrere Releases hinweg vorzubereiten, während KI-gestützte Vorab-Prüfung und proaktive Sicherheitstests eingesetzt werden, um Probleme schon vor einem Release zu erkennen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
InfoQ: Thank you for taking the time to answer some questions for our readers. Let's start by introducing yourselves.
Olson: I am Madelyn Olson, and I helped create the fork after the license change. I work at AWS and serve on Valkey’s technical steering committee (TSC). Before Valkey, I was a Redis committer as well.
Söderqvist: I am Viktor Söderqvist, and I work on open source at Ericsson and was also involved in creating the fork.
InfoQ: What did the 8.x releases change technically?
Olson: The theme was foundational infrastructure. Async I/O threading increased throughput from approximately 200,000-250,000 requests per second to around one million per process. Unlike the previous I/O-thread arrangement, thread configuration can be changed at runtime, allowing operators to add cores to help handle burst workloads. Versions 8.0 and 8.1 also included memory-efficiency work involving key embedding and the per-slot dictionary.
Dual-channel replication addressed pressure on a primary during replica synchronisation. Previously, a full copy of the dataset and the subsequent stream of replication changes were sent sequentially. Sending them in parallel reduces the memory pressure associated with that process.
InfoQ: Why were the version 9 cluster changes important?
Olson: Cluster mode distributes keys by slot across nodes, but moving to it had two significant limitations. Cross-slot operations require data to reside on the same shard, and cluster mode previously did not support numbered databases, the namespaces available in single-instance deployments. Adding numbered databases removed one reason some users could not migrate to cluster mode.
Atomic slot migration addressed another problem: moving data key by key could leave a cluster partially migrated if the operation failed. The new approach pre-stages the data and then switches over, so the migration either takes effect or does not. Version 9 also introduced hash-field expiration, described as one of the project’s most requested features. The interviewees cited Mastodon-style deployments, multiple servers using one cluster, as an example of demand for the cluster changes, while cautioning against treating that arrangement as strong multi-tenancy.
InfoQ: What problem is the GLIDE client library designed to solve?
Olson and Söderqvist: Redis clients originally had a relatively simple task: communicate with a single node. Cluster topology, TLS, redirects, reconnects, and connection pooling made client behaviour more complex, and different language clients implemented those features inconsistently. Glide, which began as an AWS project, puts connection and topology handling in a shared Rust core and exposes it through language-specific bindings. A bug fixed in the core can therefore be fixed for all the bindings that use it.
WebAssembly was considered, but the team judged it too early for the approach at the time. Glide is not intended to eliminate native alternatives: Valkey continues to support other clients, including Go implementations, for users whose needs are already met by them.
InfoQ: What could take Valkey beyond its current caching use cases?
Olson and Söderqvist: One proposed direction is synchronous replication, with the aim of providing durability guarantees for data that is not merely ephemeral. Another is tiering: keeping hot data in memory while moving colder data to SSD or other storage.
Olson: Tiering may need more than one strategy. Small, infrequently accessed keys could be moved out of DRAM; sufficiently large objects might instead remain on disk and be streamed directly to the network. The team is considering a more general interface that could support backends beyond local NVMe, such as S3 or Postgres. Parquet was discussed as potentially useful for change-data-capture or clickstream output, rather than as the format for dynamically reading and rewriting tiered data. Cross-cluster active-active replication with eventual consistency remains a longer-term idea, not an implementation commitment.
Besides features, the project is also investing in release and security work. Automated backporting is intended to shorten the time needed to prepare fixes across releases, while AI-assisted pre-review and proactive security testing are being used to identify problems before a release.