Au cœur de la performance exceptionnelle de Redis se trouve sa bibliothèque de gestion d'événements nommée ae (Asynchronous Events). Ce composant minimaliste et efficace orchestre les interactions réseau et les tâches planifiées au sein d'une boucle d'événements unique. En encapsulant les mécanismes de multiplexage d'E/S spécifiques aux systèmes d'exploitation, ae permet à Redis de traiter des milliers de requêtes simultanées avec une latence minimale.

Conception et Structures Fondamentales de la Bibliothèque ae

La bibliothèque ae repose sur une abstraction qui masque la complexité des appels système comme epoll sous Linux ou kqueue sous BSD. Sa conception privilégie la légèreté pour éviter tout goulot d'étranglement CPU.

Structures de données clés

Pour gérer les différents types d'activités, Redis définit trois structures principales : les événements de fichiers, les événements temporels et la boucle de contrôle principale.

/* Représentation d'un événement sur un descripteur de fichier */
typedef struct redisFileEvent {
    int type_mask;               /* AE_READABLE ou AE_WRITABLE */
    aeFileProc *read_handler;    /* Callback pour la lecture */
    aeFileProc *write_handler;   /* Callback pour l'écriture */
    void *private_data;          /* Données contextuelles */
} redisFileEvent;

/* Structure pour les tâches planifiées (timers) */
typedef struct redisTimeEvent {
    long long event_id;          /* Identifiant unique */
    long scheduled_sec;          /* Temps d'exécution (secondes) */
    long scheduled_ms;           /* Temps d'exécution (millisecondes) */
    aeTimeProc *process_func;    /* Fonction de traitement */
    aeEventFinalizerProc *finalizer; 
    void *private_data;
    struct redisTimeEvent *next; /* Liste chaînée */
} redisTimeEvent;

/* État global de la boucle d'événements */
typedef struct redisEventLoop {
    int max_fd_registered;       /* Plus haut descripteur de fichier */
    int capacity;                /* Taille du jeu de descripteurs */
    long long next_timer_id;
    redisFileEvent *events;      /* Tableau des événements enregistrés */
    aeFiredEvent *fired;         /* Événements ayant déclenché */
    redisTimeEvent *timer_list;  /* Liste des timers */
    int is_stopped;
    void *api_context;           /* Données spécifiques à l'OS (epoll_state, etc.) */
    aeBeforeSleepProc *pre_sleep_hook;
} redisEventLoop;

Mécanisme de Multiplexage et Ordonnancement

L'efficacité de Redis provient de sa capacité à combiner les événements réseau (I/O) et les événements temporels (timers) dans un flux unique. Le cœur de cet ordonnancement se trouve dans la fonction de traitement de la boucle.

Algorithme de traitement des événements

Le cycle de vie d'une itération de la boucle d'événements suit une logique précise pour minimiser l'attente active :

1. Calcul du timeout : Le système identifie le timer le plus proche dans la liste timer_list.
2. Appel système bloquant : Le multiplexeur (ex: epoll_wait) est appelé avec un timeout correspondant au délai avant le prochain timer. Si des données réseau arrivent entre-temps, l'appel retourne immédiatement.
3. Exécution des E/S : Les callbacks associés aux descripteurs de fichires prêts (lecture ou écriture) sont exécutés.
4. Traitement des timers : La liste des événements temporels est parcourue, et ceux dont l'échéance est dépassée sont déclenchés.

/* Exemple simplifié de la logique de traitement */
int process_all_events(redisEventLoop *loop, int flags) {
    int handled = 0;
    struct timeval timeout, *tvp = NULL;

    // Déterminer le temps d'attente max en fonction du prochain timer
    redisTimeEvent *closest_timer = find_nearest_timer(loop);
    if (closest_timer) {
        long now_sec, now_ms;
        get_current_time(&now_sec, &now_ms);
        calculate_relative_timeout(closest_timer, now_sec, now_ms, &timeout);
        tvp = &timeout;
    }

    // Attente des événements réseau via l'API système (epoll/select)
    int num_fired = aeApiPoll(loop, tvp);

    for (int i = 0; i < num_fired; i++) {
        int fd = loop->fired[i].fd;
        redisFileEvent *fe = &loop->events[fd];
        
        if (loop->fired[i].mask & AE_READABLE)
            fe->read_handler(loop, fd, fe->private_data, AE_READABLE);
        if (loop->fired[i].mask & AE_WRITABLE)
            fe->write_handler(loop, fd, fe->private_data, AE_WRITABLE);
        
        handled++;
    }

    // Traitement des timers après les E/S
    handled += run_timers(loop);
    return handled;
}

Adaptation aux Spécificités de Windows (IOCP)

Bien que Redis soit nativement conçu pour les systèmes POSIX, son architecture permet une adaptation sur Windows via les I/O Completion Ports (IOCP). Contrairement à epoll qui est basé sur la notification de disponibilité (readiness), IOCP repose sur la notification de complétion.

Pour maintenir une interface cohérente, la couche d'abstraction sous Windows simule le comportement de ae en utilisant des structures OVERLAPPED pour les opérations asynchrones. Lorsqu'une opération de lecture se termine, l'événement est placé dans une file de complétion que la boucle ae traite lors de son appel à l'API de polling.

Gestion des Connexions et E/S Non-Bloquantes

Tous les sockets gérés par Redis sont configurés en mode non-bloquant. Cela garantit que le thread unique de Redis ne reste jamais suspendu sur une opération réseau lente.

Cycle de vie d'un client

Lorsqu'un nouveau client se connecte, Redis procède comme suit :

• Acceptation : Le socket d'écoute déclenche un événement de lecture.
• Configuration : Le nouveau descripteur de fichier est configuré avec O_NONBLOCK et TCP_NODELAY (pour désactiver l'algorithme de Nagle et réduire la latence).
• Enregistrement : Un événement de lecture est ajouté à la boucle ae pour surveiller les commandes envoyées par ce client.

/* Configuration d'un socket en mode non-bloquant */
int set_socket_nonblocking(int fd) {
    int current_flags = fcntl(fd, F_GETFL, 0);
    if (current_flags == -1) return -1;
    return fcntl(fd, F_SETFL, current_flags | O_NONBLOCK);
}

Optimisation des Bufffers

Pour maximiser le débit, Redis sépare les tampons d'entrée et de sortie pour chaque client :

Cette architecture permet à Redis de rester extrêmement réactif. En traitant les événements de lecture, en exécutant la logique en mémoire, puis en préparant les réponses dans des buffers avant que la boucle d'événements ne signale que le socket est prêt pour l'écriture, Redis minimise les chagnements de contexte et maximise l'utilisation du cache CPU.