Comprendre le RESP : le protocole derrière Redis

Dans mon article précédent, j'ai présenté un aperçu de mon clone de Redis construit avec Node.js. Maintenant, je souhaite expliquer une partie cruciale de ce projet : le RESP, ou Redis Serialization Protocol.

Redis ne reçoit pas de jolis tableaux JavaScript. Il reçoit des octets bruts via un socket TCP. Pour fonctionner, ces octets ont besoin d'une structure. Le serveur doit savoir où une commande commence et se termine. Il doit savoir combien d'arguments existent et quelle est la longueur de chacun d'eux.

Le RESP fournit cette structure. C'est le langage que les clients et les serveurs utilisent pour communiquer.

Par exemple, la commande GET name ressemble à ceci en RESP : *2\r\n$3\r\nGET\r\n$4\r\nname\r\n

Voici le détail :

  • *2 signifie un tableau de 2 éléments.
  • $3 signifie que la partie suivante fait 3 octets : GET.
  • $4 signifie que la partie suivante fait 4 octets : name.

L'analyseur transforme ces octets en ["GET", "name"]. Le moteur peut alors exécuter la commande.

Pourquoi ne pas simplement séparer les chaînes par des espaces ? Une simple séparation échoue avec les valeurs contenant des espaces, comme SET message "hello world". Cela échoue également avec les données binaires. Le RESP résout ce problème en incluant la longueur de chaque valeur. Le serveur lit exactement le nombre d'octets spécifié. Cela le rend binary-safe et fiable.

La leçon la plus difficile a été d'apprendre que le TCP est basé sur des flux (streams) et non sur des messages. Un serveur ne reçoit pas toujours une commande complète à la fois. Une commande peut arriver en deux morceaux distincts. Ou, plusieurs commandes peuvent arriver dans un seul et même morceau.

Cela signifie que l'analyseur ne peut pas supposer qu'un événement de données correspond à une commande. L'analyseur doit utiliser un tampon (buffer) interne.

Mon analyseur RESP fonctionne ainsi :

  1. Recevoir les octets du socket.
  2. Ajouter les octets à un tampon.
  3. Tenter d'analyser une commande complète.
  4. Si la commande est incomplète, attendre plus de données.
  5. Si une commande est complète, la renvoyer.
  6. S'il reste des données supplémentaires, les conserver dans le tampon pour l'analyse suivante.

Une base de données commence à la couche protocole. Avant que Redis ne puisse stocker des données, il doit comprendre la commande. Avant de renvoyer une valeur, il doit encoder la réponse.

L'implémentation du RESP a transformé un simple serveur TCP en un véritable système compatible avec Redis. Cela a changé ma vision des systèmes backend. Un protocole est plus qu'un format. C'est un contrat entre deux systèmes.

Dans mon prochain article, je traiterai de la couche de stockage en mémoire.

Dépôt : https://github.com/Abhinov007/redis_clone Bac à sable en direct : https://abhinov007.github.io/Redis_Clone/ Source : https://dev.to/abhinov007/understanding-resp-the-protocol-behind-redis-50p4