RESP3-Protokoll: was sich gegenüber RESP2 in der Praxis ändert

1. Die Ausgangslage: RESP2 als jahrzehntelanger Standard

RESP2, das Redis Serialization Protocol in seiner zweiten Version, ist seit den frühesten Redis-Versionen im Einsatz und kennt nur eine überschaubare Anzahl grundlegender Antworttypen: einfache Strings, Fehler, Ganzzahlen, Bulk Strings für binäre oder längere Textdaten und Arrays, die verschachtelt werden können, um komplexere Strukturen wie Hash- oder Sorted-Set-Antworten abzubilden. Alles, was semantisch mehr Struktur hätte, etwa eine Zuordnung von Schlüsseln zu Werten, wird als flaches Array mit abwechselnd Schlüssel und Wert kodiert, und die Client-Bibliothek muss selbst wissen, dass ein bestimmter Befehl ein solches Array eigentlich als Map interpretieren sollte.

Diese Einfachheit war lange ein Vorteil, weil sie das Protokoll leicht zu implementieren machte, führte aber dazu, dass die eigentliche Datenstruktur eines Befehlsergebnisses implizit im Wissen der Client-Bibliothek steckte statt explizit im Protokoll selbst. Für neue Datentypen wie Doubles bei ZSCORE oder echte Boolesche Werte gab es in RESP2 keine eigene Repräsentation, sie wurden als Bulk String oder Ganzzahl kodiert und mussten von der Anwendung selbst interpretiert werden.

2. Neue Datentypen in RESP3: Maps, Sets, Doubles und mehr

RESP3 führt eine Reihe expliziter neuer Typen ein, die semantisch genauer abbilden, was ein Befehl tatsächlich zurückgibt. Der Map-Typ, eingeleitet mit %, kodiert Schlüssel-Wert-Zuordnungen explizit als solche, statt sie als flaches Array zu tarnen, sodass etwa HGETALL unter RESP3 eine echte Map statt eines Arrays zurückliefert. Der Set-Typ, eingeleitet mit ~, macht dasselbe für Befehle wie SMEMBERS, deren Ergebnis semantisch eine ungeordnete Menge ohne Duplikate ist.

Für Zahlen mit Nachkommastellen führt RESP3 den Double-Typ mit dem Präfix , ein, sodass Befehle wie ZSCORE nun einen echten Gleitkommawert liefern, den Client-Bibliotheken direkt als Zahl parsen können, statt einen Bulk String manuell in eine Zahl umwandeln zu müssen. Zusätzlich gibt es einen Boolean-Typ mit dem Präfix #, einen Big-Number-Typ mit ( für Werte, die den Wertebereich normaler 64-Bit-Ganzzahlen sprengen, sowie einen expliziten Null-Typ mit _, der die bisherige Doppeldeutigkeit zwischen leerem Bulk String und Null auflöst.

# RESP2: HGETALL liefert ein flaches Array
*4
$4
name
$5
Alice
$3
age
$2
30

# RESP3: HGETALL liefert eine echte Map
%2
$4
name
$5
Alice
$3
age
$2
30

3. Push-Nachrichten: der entscheidende strukturelle Unterschied

Der vielleicht wichtigste strukturelle Unterschied ist der neue Push-Typ mit dem Präfix >. Push-Nachrichten sind Server-Nachrichten, die außerhalb des normalen Anfrage-Antwort-Zyklus über dieselbe Verbindung eintreffen können, ohne dass der Client zuvor eine passende Anfrage gestellt hat. Genau darauf baut das im Client-Side-Caching-Kontext genutzte Tracking-Protokoll auf: Invalidierungsnachrichten treffen als Push-Nachrichten ein, unabhängig davon, ob der Client gerade auf eine andere Antwort wartet.

Auch PubSub-Nachrichten lassen sich unter RESP3 als Push-Nachrichten statt als normale Array-Antworten übertragen, was Client-Bibliotheken erlaubt, Subscribe-Nachrichten und normale Befehlsantworten technisch sauber zu trennen, statt beide Typen anhand des Array-Inhalts unterscheiden zu müssen wie unter RESP2. RESP2 kennt diesen Mechanismus schlicht nicht, weshalb Funktionen wie Client-Side Caching mit Tracking zwingend RESP3 voraussetzen.

4. Protokollumschaltung über HELLO: wie ein Client RESP3 aktiviert

Eine Redis-Verbindung startet standardmäßig im RESP2-Modus, um mit älteren Clients kompatibel zu bleiben. Ein Client, der RESP3 nutzen möchte, sendet nach dem Verbindungsaufbau den Befehl HELLO 3, woraufhin der Server ab diesem Zeitpunkt für die gesamte weitere Verbindung im RESP3-Modus antwortet. Der HELLO-Befehl übernimmt dabei zusätzlich Aufgaben, die früher separat über AUTH und SELECT erledigt wurden, sodass sich Authentifizierung, Datenbankauswahl und Protokollumschaltung in einem einzigen Roundtrip erledigen lassen.

Wichtig ist, dass die Protokollumschaltung pro Verbindung gilt, nicht global für den Server: Zwei gleichzeitig geöffnete Verbindungen können unterschiedliche Protokollversionen nutzen, was einen schrittweisen Umstieg innerhalb einer Anwendung erlaubt, ohne dass sofort der gesamte Verbindungspool umgestellt werden müsste.

# Verbindung auf RESP3 umschalten, inklusive Authentifizierung
redis-cli
> HELLO 3 AUTH myuser mypassword
1# "server" => "redis"
2# "proto" => (integer) 3
3# "id" => (integer) 42
...

# Ohne HELLO bleibt eine Verbindung im RESP2-Modus

5. Client-Bibliotheken-Kompatibilität: worauf man in der Praxis achten muss

Nicht jede Redis-Client-Bibliothek unterstützt RESP3 gleich vollständig. Ausgereifte, aktiv gepflegte Bibliotheken für gängige Sprachen bieten meist eine explizite Konfigurationsoption, mit der sich RESP3 aktivieren lässt, während sie standardmäßig weiterhin im kompatibleren RESP2-Modus arbeiten, um bestehende Anwendungen nicht ungefragt zu verändern. Ältere oder weniger aktiv gepflegte Bibliotheken unterstützen mitunter nur RESP2 und liefern beim Versuch, HELLO 3 zu senden, entweder einen Protokollfehler oder ignorieren die neuen Typen stillschweigend.

Für PHP-Anwendungen mit gängigen Redis-Erweiterungen ist die Unterstützung inzwischen weit fortgeschritten, wichtig ist aber, vor einer Umstellung explizit zu prüfen, ob die konkret eingesetzte Version der Bibliothek RESP3-Antworttypen korrekt in die erwarteten PHP-Datentypen übersetzt, insbesondere bei Maps, die anders als flache Arrays gehandhabt werden müssen, und bei Doubles, die nun als PHP-Float statt als String ankommen.

6. Praktische Auswirkung auf eigenen Anwendungscode

Für Anwendungen, die eine moderne Client-Bibliothek mit vollständiger RESP3-Unterstützung nutzen, bleibt die Umstellung meist unsichtbar: Die Bibliothek übersetzt Maps, Sets und Doubles transparent in die jeweiligen nativen Datentypen der Programmiersprache, und der Anwendungscode, der etwa das Ergebnis von HGETALL als assoziatives Array behandelt, funktioniert unter RESP2 wie unter RESP3 identisch.

Auffällig wird der Unterschied vor allem bei Code, der auf konkrete Rückgabetypen prüft, etwa mit is_string() oder is_array() in PHP, oder bei Code, der Debug-Ausgaben oder Logging direkt auf Basis der rohen Protokollantwort erstellt. Wer ZSCORE-Ergebnisse bislang als String weiterverarbeitet hat, etwa durch String-Konkatenation, kann unter RESP3 auf einen Float statt eines Strings stoßen, was in schwach typisierten Sprachen selten zu Fehlern führt, in streng typisiertem Code aber explizite Anpassungen nötig machen kann.

{
  "zscore_result_resp2": "3.5",
  "zscore_result_resp3": 3.5,
  "hgetall_result_resp2": ["name", "Alice", "age", "30"],
  "hgetall_result_resp3": {"name": "Alice", "age": "30"}
}

7. Umstellung schrittweise angehen statt Big-Bang-Wechsel

Ein pauschaler, sofortiger Umstieg der gesamten Anwendung auf RESP3 ist selten nötig, da RESP2 auch langfristig unterstützt bleibt und beide Protokollversionen parallel auf demselben Redis-Server funktionieren. Sinnvoller ist es, RESP3 gezielt dort zu aktivieren, wo ein konkreter Vorteil entsteht, etwa bei Verbindungen, die Client-Side Caching mit Tracking nutzen sollen, während der Rest der Anwendung zunächst unverändert im RESP2-Modus verbleibt.

Vor einer breiteren Umstellung lohnt sich ein Testlauf gegen eine Staging-Umgebung mit realistischer Last, bei dem gezielt auf Stellen im Code geachtet wird, die Rückgabetypen prüfen oder rohe Protokollantworten verarbeiten. Automatisierte Tests, die typische Befehlsergebnisse wie HGETALL, ZSCORE und SMEMBERS gegen erwartete Datentypen prüfen, decken die meisten praktischen Stolperfallen zuverlässig auf.

8. Rückwärtskompatibilität: warum RESP2 nicht verschwindet

Redis-Server unterstützen RESP2 und RESP3 gleichzeitig und dauerhaft, es gibt keine Ankündigung, RESP2 in absehbarer Zeit abzuschaffen. Das ist bewusst so gewählt, weil ein riesiges Ökosystem an bestehenden Anwendungen, Bibliotheken und Tools auf RESP2 aufbaut, und ein erzwungener Wechsel enorme Kompatibilitätsprobleme verursachen würde. Neue Funktionen, die technisch auf RESP3 angewiesen sind, wie das Tracking-Protokoll für Client-Side Caching, funktionieren deshalb ausschließlich über RESP3-Verbindungen, während der übrige Funktionsumfang von Redis unter beiden Protokollversionen gleichermaßen nutzbar bleibt.

Für die Praxis bedeutet das: RESP3 ist keine Pflicht, sondern eine Option, die man dort aktiviert, wo sie einen konkreten funktionalen oder strukturellen Vorteil bringt. Wer keine der RESP3-exklusiven Funktionen benötigt, kann ohne Nachteile dauerhaft bei RESP2 bleiben.

9. Debugging und Diagnose: Protokollversion einer Verbindung erkennen

Bei der Fehlersuche in Verbindungsproblemen ist es hilfreich zu wissen, in welchem Protokollmodus eine bestehende Verbindung tatsächlich läuft. Der Befehl CLIENT INFO liefert unter anderem das Feld resp, das die aktive Protokollversion für die aufrufende Verbindung anzeigt, und CLIENT LIST liefert dieselbe Information für alle aktiven Verbindungen auf dem Server, was sich gut eignet, um zu prüfen, ob eine erwartete RESP3-Umstellung tatsächlich bei allen relevanten Verbindungen angekommen ist.

Bei unerwartetem Anwendungsverhalten nach einer teilweisen RESP3-Umstellung lohnt sich als erster Diagnoseschritt oft der Blick auf genau dieses Feld, da ein vergessener HELLO 3-Aufruf in einer bestimmten Verbindungspool-Konfiguration eine häufige, aber leicht zu übersehende Fehlerursache ist.

# Protokollversion der aktuellen Verbindung anzeigen
redis-cli -3 CLIENT INFO
# id=42 addr=... resp=3 ...

# Protokollversionen aller aktiven Verbindungen auflisten
redis-cli CLIENT LIST

10. Zusammenfassung

11. FAQ: RESP3-Protokoll: Das Wichtigste auf einen Blick