Philosophie de l'ingénierie : Salvatore Sanfilippo (antirez)

Points clés à retenir

• Son principe directeur est d’en faire moins — un système petit et simple que l’on peut tenir tout entier dans sa tête vaut mieux qu’un système vaste et complet en fonctionnalités. Salvatore Sanfilippo, connu en ligne sous le nom d’antirez, a conçu Redis comme un magasin délibérément réduit : mono-thread, en mémoire, écrit dans un C limpide et farouchement réfractaire aux fonctionnalités qui le rendraient plus difficile à comprendre. Ses essais reviennent inlassablement sur la même cible — la complexité que l’on ajoute sans jamais en mesurer le coût.¹⁵
• Il a créé Redis en 2009, et celui-ci est devenu l’une des bases de données les plus utilisées au monde. Redis — le magasin de structures de données en mémoire — a été publié pour la première fois le 26 février 2009, né de sa tentative de faire passer à l’échelle sa startup italienne LLOOGG, un analyseur de journaux web en temps réel. Il en a été le seul mainteneur et le « Dictateur bienveillant à vie » pendant onze ans.¹²
• Redis est mono-thread par conception, et c’est une fonctionnalité. Plutôt que de courir après le débit multicœur, Redis exécute les commandes une à une sur un unique thread — ce qui élimine les conditions de concurrence et la surcharge des verrous, garde le modèle simple, et reste assez rapide parce que, comme le dit la FAQ de Redis, « il est assez rare que le CPU devienne votre goulot d’étranglement avec Redis, car Redis est généralement limité par la mémoire ou le réseau ».⁷
• Il considère le code comme quelque chose qui est écrit par des humains pour d’autres humains. Dans ses essais « Writing system software », il soutient que le code source « devrait être lu autant qu’exécuté, puisqu’il est écrit par des humains pour d’autres humains », et que le but d’un code lisible est « d’abaisser la quantité d’efforts et le nombre de détails que le lecteur doit garder en tête ».⁴

Le principe

« Nous détruisons le logiciel en ne tenant plus compte de la complexité lorsque nous ajoutons des fonctionnalités ou optimisons une dimension… Nous détruisons le logiciel par une chaîne absurde de dépendances, qui rend tout boursouflé et fragile… Nous détruisons le logiciel en fabriquant des systèmes qui ne savent plus se réduire : les choses simples devraient être simples à accomplir, dans n’importe quel système. » — Salvatore Sanfilippo, « We are destroying software »⁵

L’essentiel de l’ingénierie consiste à ajouter. On réclame une fonctionnalité, alors on l’ajoute. Une dépendance ferait gagner une semaine, alors on l’intègre. Une optimisation aiderait un seul utilisateur, alors on l’inscrit au cœur du système. Chaque pas paraît localement raisonnable — et la somme donne un système que plus personne ne peut tenir dans sa tête. L’instinct de Sanfilippo va en sens inverse. La ligne de code la plus dangereuse, dans sa philosophie, est celle que l’on écrit sans s’être d’abord demandé si l’on pouvait éviter de l’écrire. En faire moins. La question n’est jamais « que peut faire de plus cet outil ? », mais « que peut-il cesser de faire tout en restant digne d’usage ? ».⁵

L’expression la plus nette du principe, c’est Redis lui-même. Il est mono-thread pour l’exécution des commandes — un choix qui, en 2009, paraissait presque pervers alors que l’industrie se précipitait pour exploiter les multiples cœurs.¹⁷ Mais le raisonnement, c’est le principe transformé en architecture. Un thread unique exécutant une commande à la fois n’a aucune condition de concurrence, aucun verrou, aucune lecture corrompue, aucun bug de deux threads mutant la même clé. Le modèle mental se réduit à quelque chose qu’une personne peut réellement appréhender : les commandes se succèdent, dans l’ordre, atomiquement. Et l’on n’y perd presque rien en pratique, car Redis est « limité par la mémoire ou le réseau » bien avant que le CPU ne devienne la limite.⁷ La complexité de la concurrence était un coût qu’antirez refusait de payer pour un bénéfice dont la plupart des charges de travail n’avaient jamais besoin.

Ce refus voyage avec deux compagnons qui le rendent abordable. Le premier, ce sont des primitives riches : au lieu de forcer chaque problème à passer par un unique modèle clé-valeur, Redis livre des chaînes, des hachages, des listes, des ensembles, des ensembles ordonnés et des flux comme structures de données natives, si bien que le bon outil est généralement déjà dans la boîte.¹ Le second, c’est un code écrit pour les humains : il insiste sur le fait que le code source est « écrit par des humains pour d’autres humains », et qu’un bon code abaisse « le nombre de détails que le lecteur doit garder en tête ».⁴ Donnez aux gens quelques primitives puissantes, faites-en moins qu’ils ne le demandent, et écrivez l’ensemble de telle sorte qu’une seule personne puisse encore le comprendre. Voilà le principe, et Redis en est la preuve.

Le contexte

Salvatore Sanfilippo est né le 7 mars 1977 à Campobello di Licata, en Sicile, en Italie.¹ Il a grandi dans une région marginalisée du sud de la Sicile, près de Gela, et a déménagé à Palerme à dix-sept ans pour étudier l’architecture — un diplôme qu’il n’a jamais achevé, réorientant son attention vers l’informatique et apprenant à programmer en grande partie par lui-même.¹ Le détail qui mérite d’être retenu, c’est qu’il est autodidacte, sans diplôme universitaire d’informatique mené à son terme ; le métier est venu de la pratique, non d’un titre. C’est une figure récurrente dans cette série — le praticien chevronné dont l’autorité repose sur ce qu’il a construit, non sur ce qu’on lui a enseigné.

Sa première empreinte dans le domaine fut dans la sécurité, non dans les bases de données. Il a écrit hping, un générateur et analyseur de paquets open source pour le protocole TCP/IP, utilisé pour les tests de sécurité.¹ Plus marquant encore, en 1998 il a publié l’idle scan — une technique de balayage de ports furtif, d’abord appelée « dumb scan », qui détermine quels services sont ouverts sur une cible « sans laisser de traces remontant jusqu’à soi ».⁶ Elle fonctionne en exploitant un canal auxiliaire : un hôte tiers « zombie » inactif aux compteurs d’identifiants IP prévisibles, que l’attaquant utilise comme relais aveugle pour déduire les réponses de la cible.⁶ La technique était assez astucieuse pour être incorporée dans nmap et hping, où elle figure toujours.⁶ C’est le même instinct qui définira plus tard Redis — trouver le mécanisme élégant qui se cache sous un problème apparemment ardu.

Redis lui-même est né d’un problème concret de mise à l’échelle. À la fin des années 2000, Sanfilippo faisait tourner LLOOGG, une startup italienne bâtissant un analyseur de journaux web en temps réel, et les bases de données existantes ne tenaient pas le rythme d’écriture dont il avait besoin.¹ Alors en 2009 il a construit son propre magasin en mémoire, et a publié Redis le 26 février 2009.¹² Il s’est répandu vite, et les parrainages ont suivi son ascension : VMware l’a embauché en mars 2010, Pivotal Software (une émanation de VMware) a repris le parrainage en mai 2013, et Redis Ltd. l’a assumé en juin 2015.¹ Il a été le seul mainteneur du projet et son BDFL pendant onze ans, puis s’est retiré le 30 juin 2020, remplacé par Yossi Gottlieb et Oran Agra.¹ En décembre 2024 il est revenu à Redis comme évangéliste et contributeur actif — le rare créateur qui est parti au sommet et qui est revenu.¹

Le travail

Redis et ses structures de données : des primitives puissantes, pas un magasin clé-valeur vierge

Commençons par ce qui rend Redis différent, car c’est le principe transformé en produit. La plupart des magasins clé-valeur vous donnent exactement cela — une clé, un blob opaque en guise de valeur, et la charge de bâtir vous-même tout le reste. Redis, lui, livre des structures de données riches comme primitives : chaînes, hachages, listes, ensembles, ensembles ordonnés et — depuis Redis 5.0 — flux.¹ Chacune est un type natif, côté serveur, doté de ses propres commandes, si bien que la structure de données que vous auriez assemblée à la main dans le code applicatif vit déjà dans la base, manipulée atomiquement par cet unique thread.¹⁷ Le gain, c’est que des fonctionnalités applicatives ardues se réduisent à une poignée de commandes, parce que la bonne primitive est déjà là.

L’exemple le plus tranchant est l’ensemble ordonné (ZSET). C’est une collection de membres uniques, chacun portant un score à virgule flottante, et Redis garde les membres « pris dans l’ordre » — l’ordonnancement est une propriété de la structure de données elle-même, et non quelque chose calculé à la demande.³ Sous le capot, c’est une structure à double accès, une skip list associée à une table de hachage, qui offre des insertions en O(log(N)) et zéro travail supplémentaire pour relire les résultats déjà triés.³ On ajoute ou met à jour le score d’un membre avec ZADD, et on lit le rang d’un membre avec ZRANK (du plus bas au plus haut) ou ZREVRANK (du plus haut au plus bas).³ Le cas d’usage canonique est celui dont chaque jeu a besoin et que chaque base de données traditionnelle redoute : le classement (leaderboard). Comme le disent les docs de Redis : « vous pouvez utiliser les ensembles ordonnés pour maintenir facilement des listes ordonnées des meilleurs scores dans un jeu en ligne massif ».³

Pourquoi cela compte en tant qu’ingénierie : un classement dans une base de données relationnelle est une véritable plaie. Chaque changement de score signifie un UPDATE, et chaque requête « quel rang occupe ce joueur ? » signifie un ORDER BY sur toute la table ou un index maintenu — un travail qui croît avec le nombre de joueurs et entre en contention sous la charge. Dans Redis, le classement est intrinsèque à la structure. ZADD coûte O(log(N)) et ZREVRANK coûte O(log(N)), et l’ensemble est déjà trié, si bien que lire le top dix est trivial.³ La fonctionnalité n’est pas devenue plus facile parce que Redis serait plus rapide à accomplir le même travail — elle est devenue plus facile parce que Sanfilippo a choisi de livrer une primitive dont la forme est la solution. C’est « en faire moins » du côté de l’utilisateur : la base a fait le plus dur une seule fois, pour que mille applications n’aient jamais à le faire.

Mono-thread et en mémoire : la simplicité comme centre de gravité de la conception

Redis fait deux choix qui ressemblent à des limitations et qui sont en réalité la source de sa force. Il est en mémoire — le jeu de données de travail vit en RAM, la durabilité étant ajoutée par-dessus au moyen d’instantanés et d’un fichier en ajout seul — et il est mono-thread pour l’exécution des commandes, traitant les requêtes une à une sur un seul cœur.¹⁷ Les deux choix sont « en faire moins » déguisé.

La décision du thread unique est la plus contre-intuitive, et le raisonnement mérite qu’on le suive. Un magasin multi-thread doit coordonner l’accès concurrent aux données partagées — verrous, atomiques, structures sans verrou, barrières mémoire — et c’est dans cette machinerie que se loge une part effrayante des bugs de bases de données et des latences imprévisibles. En n’exécutant qu’une commande à la fois, Redis rend chaque commande atomique par construction : aucun entrelacement à raisonner, aucun verrou à oublier, aucune course à déboguer.⁷ La FAQ officielle est franche sur le fait que cela coûte si peu : « Il est assez rare que le CPU devienne votre goulot d’étranglement avec Redis, car Redis est généralement limité par la mémoire ou le réseau », et le mono-threading « évite les conditions de concurrence et les changements de contexte gourmands en CPU associés aux threads ».⁷ Le débit auquel la conception renonce est un débit que la plupart des charges de travail n’allaient de toute façon jamais utiliser ; la simplicité qu’elle achète est remboursée sur chaque ligne de code et à chaque session de débogage à 3 heures du matin.

C’est le même tempérament que son refus, dans les essais, d’ajouter de la complexité. Il décrit le mode de défaillance avec précision : « Nous détruisons le logiciel en ne tenant plus compte de la complexité lorsque nous ajoutons des fonctionnalités ou optimisons une dimension. »⁵ Le multi-threading est exactement le genre d’optimisation — d’une seule dimension, le débit CPU brut — qui aurait multiplié la complexité du système pour un bénéfice dont la plupart des utilisateurs n’avaient jamais besoin. Lui dire non a maintenu Redis dans l’état d’un système qu’une seule personne pouvait tenir dans sa tête, ce qui est précisément la propriété qui a permis à une seule personne de le maintenir pendant onze ans.¹

Le métier : du C écrit pour les humains, et le plaidoyer pour les commentaires

Le troisième pan du travail n’est pas une fonctionnalité, mais une prise de position sur la façon dont le code devrait être écrit. Sanfilippo écrit Redis en C — un langage sans garde-fous, où le programmeur est responsable de chaque octet — et il traite la lisibilité de ce C comme une préoccupation de premier ordre, non comme une arrière-pensée. Son essai « Writing system software: code comments » est un plaidoyer d’une rare franchise selon lequel le code source existe d’abord comme communication. Le code, écrit-il, « devrait être lu autant qu’exécuté, puisqu’il est écrit par des humains pour d’autres humains ».⁴ Le comportement exécutable n’est que la moitié du travail ; l’autre moitié, c’est la personne suivante — souvent vous-même dans le futur — qui doit le comprendre.

De cette prémisse il tire une théorie opérante des commentaires et de la clarté. Le but d’un code lisible, soutient-il, est « d’abaisser la quantité d’efforts et le nombre de détails que le lecteur doit garder en tête en lisant un code ».⁴ Un commentaire gagne sa place lorsqu’il supprime un détail que le lecteur devrait sinon reconstituer — le pourquoi derrière un choix non évident, l’invariant qu’une fonction présuppose, la raison d’être d’un chemin rapide. C’est le métier au sens le plus profond : non pas l’astuce, mais le soin porté à l’humain qui vient après. Cela s’accorde exactement avec le principe « en faire moins », car plus le système est petit et simple, moins il y a de détails à porter, et plus le code peut être honnête sur ceux qui demeurent.

La même conviction nourrit sa critique plus large de la direction que prend le logiciel. Il met en garde contre « une chaîne absurde de dépendances, qui rend tout boursouflé et fragile », et contre des systèmes « qui ne savent plus se réduire : les choses simples devraient être simples à accomplir, dans n’importe quel système ».⁵ Redis est son contre-argument rendu exécutable — un système aux dépendances rares, au noyau réduit et compréhensible, et conçu de telle sorte que la chose simple reste simple. Le métier n’est pas un ornement posé par-dessus l’ingénierie ; il est l’ingénierie.

La méthode

Parcourez Redis, l’idle scan, les essais sur les commentaires et la complexité, et le thread unique, et les mêmes engagements reviennent. La méthode de Sanfilippo tient moins du slogan que d’un ensemble d’habitudes permanentes.

En faire moins — le code le plus dangereux est celui que vous n’aviez pas besoin d’écrire. L’habitude directrice est la soustraction : avant d’ajouter une fonctionnalité, une dépendance ou une optimisation, demandez-vous si le système peut survivre sans elle. Il nomme le mode de défaillance directement — la complexité ajoutée « sans en tenir compte ».⁵ La leçon dépasse de loin les bases de données : chaque ligne que vous n’écrivez pas est une ligne qui ne peut pas casser, ne peut pas embrouiller le prochain lecteur, et ne peut pas exiger d’être maintenue pendant une décennie. C’est le produit minimal digne d’intérêt au niveau du cœur d’un système — livrer la plus petite chose qui soit véritablement digne d’usage, et défendre sa petitesse contre la pression constante de grossir.

Livrer des primitives puissantes, et non des politiques préassemblées. Redis vous remet des ensembles ordonnés, des flux et des hachages — des structures générales à partir desquelles vous bâtissez classements, files d’attente et limiteurs de débit — plutôt qu’une fonctionnalité sur mesure pour chacun.³ L’habitude permanente est de trouver le mécanisme sous-jacent qui résout toute une classe de problèmes et de livrer cela, pour que la base fasse le plus dur une seule fois. C’est le même pari que Roberto Ierusalimschy a fait avec les tables et métatables de Lua — donner aux gens des leviers tranchants et généraux et les laisser bâtir le reste — et la parenté n’est pas fortuite, puisque Redis embarque Lua pour faire exactement cela.

Choisir la simplicité même au prix du débit. La conception mono-thread en est le cas le plus net : Redis renonce au parallélisme multicœur pour l’exécution des commandes parce que la simplicité — pas de courses, pas de verrous, atomique par construction — vaut plus que les cœurs, et que le CPU était de toute façon rarement le goulot d’étranglement.⁷ La discipline consiste à savoir quelle dimension vous contraint réellement et à refuser de payer en complexité l’optimisation d’une dimension qui ne vous contraint pas. C’est la barrière des preuves appliquée à la performance : n’ajoutez pas de la concurrence parce que cela sonne rapide ; mesurez où se trouve réellement le goulot d’étranglement, et la plupart du temps ce n’est pas le CPU.

Écrire du code pour l’humain qui le lira ensuite. Le code source « est écrit par des humains pour d’autres humains », et le rôle d’un commentaire est d’abaisser le nombre de détails que le lecteur doit porter.⁴ L’habitude est de traiter la lisibilité et les commentaires explicatifs comme une part de la justesse, et non comme une coquetterie à ajouter plus tard — car un système que personne ne peut comprendre est un système que personne ne peut modifier en toute sécurité. C’est le même métier centré sur l’humain que Donald Knuth a poussé à sa limite avec la programmation lettrée : le programme est un texte destiné à une personne.

Tenir le système entier dans une seule tête. Redis est resté maintenable par une seule personne pendant onze ans parce qu’il a été gardé assez petit pour être compréhensible par une seule personne.¹ L’engagement permanent est de traiter la compréhensibilité-par-un-individu comme une contrainte de conception ferme — si le système dépasse ce qu’un seul esprit peut tenir, vous avez perdu ce qui le rendait digne de confiance. C’est l’instinct de l’artisanat en solo que partagent Linus Torvalds et la tradition Unix : un outil à la tâche claire et délimitée, possédé et profondément compris plutôt qu’étalé et délégué.

La chaîne d’influence

Qui l’a façonné

La tradition Unix et C. Sanfilippo écrit des logiciels système en C, à la main, avec un soin pour chaque octet — la lignée de Thompson et Ritchie, où de petits outils font une chose bien et où le langage vous donne le contrôle total et la responsabilité totale.⁴ Son insistance sur le fait que le code est écrit pour être lu par des humains, c’est l’éthique du C lisible de cette tradition portée à l’ère des bases de données. (Influence formatrice)

La culture hacker de la sécurité et des réseaux de la fin des années 1990. Avant Redis il y a eu hping et l’idle scan — du travail de paquets bas niveau qui exigeait un modèle mental précis de TCP/IP et l’œil d’un hacker pour le canal auxiliaire élégant tapi dans un protocole.¹⁶ Cette habitude de trouver le mécanisme astucieux sous un problème apparemment ardu est la même que celle qui a produit les structures de données de Redis. (Influence directe)

La contrainte d’un produit réel. Redis n’a pas été conçu dans l’abstrait ; il a été forcé d’exister par le besoin de LLOOGG d’ingérer des journaux web plus vite que les bases existantes ne le permettaient.¹ La pression d’un problème concret et urgent — et non le désir de bâtir une base de données pour elle-même — est ce qui a façonné Redis vers le fait de faire exactement ce qui était nécessaire, et guère plus. (Influence formatrice)

Qui il a façonné

Toute une génération d’architectures applicatives. Redis est devenu le choix par défaut pour la mise en cache, le stockage de sessions, la limitation de débit, les classements en temps réel et le pub/sub — au point que « mettez Redis devant » est devenu un conseil d’ingénierie réflexe, et ses structures de données ont remodelé la façon dont les développeurs conçoivent ce qu’une base peut offrir.¹³

L’école des « primitives riches » pour les magasins de données. En prouvant qu’un magasin pouvait livrer des ensembles ordonnés et des flux comme types de première classe plutôt que comme valeurs opaques, Redis a poussé tout le domaine vers des structures de données côté serveur plus riches, et loin du modèle clé-valeur vierge. (Influence structurante du domaine)

Le plaidoyer pour les systèmes petits, affirmés, à auteur unique. Redis se dresse comme preuve opérante qu’un système délibérément réduit, maintenu par une seule personne dotée de goût, peut devenir une infrastructure mondiale — un argument qui résonne à travers chaque conception « en faire moins », à dépendances minimales et à noyau compréhensible depuis lors.⁵

Le fil conducteur

Sanfilippo siège auprès des minimalistes de cette série — les bâtisseurs qui croient que la forme la plus haute de l’ingénierie est la soustraction. Rich Hickey a tracé la ligne dans « Simple Made Easy » : simple signifie non tressé, un seul pli, un seul sujet, et la complexité est l’entrelacement que l’on ajoute par commodité et que l’on paie pour toujours. Redis est cet argument compilé en C — un thread unique pour qu’il y ait un seul sujet, et non la tresse de la concurrence ; des primitives riches pour que la structure de données ne soit pas enchevêtrée avec le code applicatif.⁵⁷ Et Roberto Ierusalimschy a bâti Lua assez petit pour qu’une seule personne le comprenne, livrant des mécanismes au lieu de politiques — le même pari que fait Redis avec ses primitives, raison pour laquelle Redis embarque Lua pour permettre aux utilisateurs de les scripter atomiquement. Tous deux descendent de l’économie Unix de Thompson et Ritchie : un outil à la tâche claire, écrit dans un C lisible, assez petit pour être compris d’un seul tenant. Là où Hickey dit gardez-le simple, pas seulement facile et Ierusalimschy dit livrez le levier, pas la règle, Sanfilippo dit : faites-en moins — donnez aux gens des primitives puissantes, exécutez-les une à la fois pour que le modèle reste dans votre tête, et écrivez chaque ligne pour l’humain qui la lira ensuite. (Passerelle de la série)

Ce que j’en retiens

La leçon que je garde d’antirez, c’est que le code que je n’écris pas est le code le plus précieux du système. Mon instinct, comme celui de la plupart des bâtisseurs, est de résoudre un problème en ajoutant — une fonctionnalité, une dépendance, un thread, une optimisation astucieuse. Redis est un argument de onze ans selon lequel l’ajout est généralement l’erreur. La conception mono-thread est celle à laquelle je pense le plus : il a décliné la chose que tout le monde disait obligatoire — exploiter les cœurs — parce que la complexité qu’elle apportait ne valait pas un bénéfice dont sa charge de travail n’avait jamais besoin.⁷ Quand je construis quelque chose aujourd’hui, la question que je lui emprunte est : « que puis-je refuser d’ajouter tout en livrant quelque chose qui vaut la peine d’être utilisé ? ». Parce que chaque ligne que j’évite est une ligne qui ne peut pas casser, ne peut pas embrouiller, et ne peut pas réclamer de maintenance pour la décennie suivante. En faire moins est plus difficile que d’en faire plus, et bien plus durable.

La seconde leçon, c’est que le code est de l’écriture, et le lecteur est une personne. Il est facile de traiter le code source comme des instructions pour une machine et de s’arrêter dès que les tests passent. Sanfilippo le traite comme une communication — « écrit par des humains pour d’autres humains » — et le juge à l’aune du peu de détails que le prochain lecteur devra porter en tête.⁴ Cela a recadré les commentaires pour moi : non du bruit à minimiser, non des excuses pour un code obscur, mais l’endroit où je remets à la personne suivante le pourquoi qu’elle ne pourrait jamais reconstituer à partir du quoi. La discipline d’écrire pour le lecteur est inséparable de la discipline d’en faire moins, car plus le système est petit et simple, plus son code peut être honnête — et plus il est probable qu’une seule personne, des années plus tard, puisse encore tenir l’ensemble dans sa tête. C’est la qualité est la seule variable lue comme retenue : la bonne petite chose, écrite pour des humains et défendue contre la boursouflure, devient l’infrastructure sur laquelle le monde peut s’appuyer.

FAQ

Qu’est-ce que Redis ?

Redis est un magasin de structures de données en mémoire, open source, créé par Salvatore Sanfilippo (antirez) et publié pour la première fois le 26 février 2009.¹² Plutôt que de stocker des valeurs opaques comme un simple cache clé-valeur, il offre des structures de données natives riches — chaînes, hachages, listes, ensembles, ensembles ordonnés et flux — manipulées atomiquement par le serveur.¹ Parce que le jeu de données de travail vit en RAM (la durabilité étant assurée par des instantanés et un fichier en ajout seul), il est extrêmement rapide, ce qui explique qu’il soit devenu l’une des bases de données les plus utilisées au monde pour la mise en cache, le stockage de sessions, les files d’attente, la limitation de débit, les classements en temps réel et le pub/sub.¹⁷

Qui est antirez ?

antirez est le pseudonyme en ligne de Salvatore Sanfilippo, un programmeur italien (sicilien) autodidacte né le 7 mars 1977 à Campobello di Licata, en Sicile.¹ Il est surtout connu comme le créateur de Redis (2009), qu’il a maintenu en tant que développeur unique et BDFL pendant onze ans avant de se retirer le 30 juin 2020 et de revenir au projet en décembre 2024.¹ Avant Redis, il a accompli un travail notable en sécurité — écrivant l’outil de paquets hping et, en 1998, inventant l’idle scan, une technique de balayage de ports furtif plus tard incorporée dans nmap.¹⁶ Il écrit avec finesse sur la simplicité, les commentaires de code et le métier du logiciel système sur son blog, à antirez.com.⁴⁵

Pourquoi Redis est-il mono-thread ?

Redis exécute les commandes une à une sur un unique thread parce que la simplicité vaut plus que le débit multicœur pour ses charges de travail. Un thread unique rend chaque commande atomique par construction — il n’y a aucune condition de concurrence, aucun verrou, et aucune lecture corrompue à raisonner.⁷ Et cela coûte peu en pratique : comme l’explique la FAQ de Redis, « il est assez rare que le CPU devienne votre goulot d’étranglement avec Redis, car Redis est généralement limité par la mémoire ou le réseau », et le mono-threading « évite les conditions de concurrence et les changements de contexte gourmands en CPU associés aux threads ».⁷ C’est le principe « en faire moins » de Sanfilippo transformé en architecture — décliner la complexité qui optimise une dimension (le CPU) qui était rarement la contrainte.⁵⁷

Qu’est-ce qu’un ensemble ordonné Redis ?

Un ensemble ordonné Redis (ZSET) est une collection de membres chaînes uniques, chacun associé à un score à virgule flottante, les membres étant gardés automatiquement dans l’ordre des scores.³ On fixe ou met à jour le score d’un membre avec la commande ZADD et on lit sa position avec ZRANK (du plus bas au plus haut) ou ZREVRANK (du plus haut au plus bas) ; la structure reste triée en permanence, si bien que lire des résultats classés ne demande aucun travail de tri supplémentaire.³ En interne, elle utilise une skip list associée à une table de hachage, ce qui donne des insertions en O(log(N)) et des recherches de rang en O(log(N)).³ L’usage classique est un classement en temps réel — une fonctionnalité pénible dans une base de données relationnelle, mais qui se réduit à deux ou trois commandes dans Redis parce que la bonne primitive existe déjà.³

Sources