excache

Une couche de cache en Elixir, utilisant le modèle d'acteurs OTP. Concurrente, résistante aux pannes de processus individuels, avec de vrais tests.

excache
TL;DR

Une couche de cache en Elixir sur le modèle d'acteurs OTP. Concurrence sans course, résilience aux pannes d'un seul processus, et de vrais tests. L'astuce consiste à s'assurer que la chute d'un élément n'entraîne pas le reste.

Introduction

Un cache partagé entre de nombreux threads est l'un des problèmes de concurrence difficiles classiques. excache montre qu'Elixir et le modèle d'acteurs OTP transforment ce problème en quelque chose que l'on peut gérer sans verrous et sans la peur sourde de l'interblocage. Au lieu de lutter contre la mémoire partagée, vous déplacez l'état là où personne n'y accède en parallèle.

C'est un projet sur deux propriétés à la fois : la concurrence sans course et la résilience aux pannes. Les deux découlent de la même philosophie OTP, où l'état vit dans un processus et les erreurs ne sont pas balayées sous le tapis mais isolées.

Le modèle d'acteurs retourne le problème de concurrence

Dans la plupart des langages, un cache partagé entre threads signifie des verrous, des mutex et la peur sourde de l'interblocage. Elixir procède autrement : chaque état vit dans un processus qui traite un message à la fois. Au lieu de verrouiller la mémoire partagée, vous envoyez un message et recevez une réponse.

La course à la structure de données n'existe tout simplement pas, parce que personne n'y accède en parallèle. La même garantie qu'il faut arracher avec des mutex dans d'autres langages est ici une propriété gratuite du modèle.

cache.ex · bash
def handle_call({:get, key}, _from, state) do
  {:reply, Map.get(state, key), state}
end

Let it crash plutôt que la défensive

En OTP vous n'enveloppez pas chaque opération dans un bloc défensif contre la panne. Au lieu de cela vous laissez le processus s'écraser, et un arbre de supervision le relève dans un état propre. C'est l'inverse de la programmation défensive : vous ne cachez pas l'erreur, vous la laissez renverser un processus et faites confiance à la supervision pour le reconstruire.

excache s'appuie directement là-dessus : la mort d'un processus de cache ne renverse pas toute la couche, car les autres processus vivent indépendamment. L'état corrompu disparaît avec le processus, et son successeur démarre propre au lieu de traîner des données cassées.

➜
Conseil

Le test de cette propriété consiste à tuer délibérément un processus en plein trafic et à vérifier que la couche répond encore. Si tout le cache tombe avec un seul processus, l'arbre de supervision est mal assemblé, et un bon test l'attrape aussitôt.

C'est un test contrefactuel dans sa forme la plus pure : vous ne vérifiez pas que le système fonctionne quand tout va bien, mais qu'il survit à la panne à laquelle il est censé survivre. Un test qui ne voit jamais un processus mourir ne prouve aucune résilience.

La résilience comme propriété, pas comme rustine

Le résultat est une couche qui traite la panne comme un état de fonctionnement normal, pas comme une exception à rustiner. La concurrence est sûre par conception, parce que personne ne partage la mémoire, et une panne isolée reste locale, parce que la supervision ne reconstruit que ce qui est tombé.

Les propriétés de la couche et d'où elles découlent

PropriétéD'où elle découle
Pas de courseun processus, un message à la fois
Pas de verrouscommunication par messages
Isolation des pannesétat enfermé dans un processus
Retour à un état proprel'arbre de supervision

Plus de projets

D'autres réalisations de la même catégorie - découvrez comment nous abordons des défis similaires.

Vous avez un projet similaire ?

Contactez-nous - le devis est gratuit et arrive sous une heure.