excache
Una capa de caché en Elixir, que usa el modelo de actores OTP. Concurrente, resistente a fallos de procesos individuales, con pruebas reales.
Una capa de caché en Elixir sobre el modelo de actores OTP. Concurrencia sin carreras, resiliencia ante fallos de un solo proceso y pruebas de verdad. El truco está en asegurar que la caída de un elemento no arrastre al resto.
Introducción
Una caché compartida entre muchos hilos es uno de los clásicos problemas difíciles de concurrencia. excache muestra que Elixir y el modelo de actores OTP convierten ese problema en algo que puedes manejar sin cerrojos y sin el miedo sordo al interbloqueo. En lugar de luchar contra la memoria compartida, trasladas el estado a donde nadie accede en paralelo.
Es un proyecto sobre dos propiedades a la vez: concurrencia sin carreras y resiliencia ante fallos. Ambas brotan de la misma filosofía OTP, en la que el estado vive en un proceso y los errores no se barren bajo la alfombra sino que se aíslan.
El modelo de actores da la vuelta al problema de la concurrencia
En la mayoría de los lenguajes una caché compartida entre hilos significa cerrojos, mutexes y el miedo sordo al interbloqueo. Elixir va por otro camino: cada estado vive dentro de un proceso que atiende un mensaje a la vez. En lugar de bloquear la memoria compartida, envías un mensaje y recibes una respuesta.
La carrera por la estructura de datos sencillamente no existe, porque nadie accede a ella en paralelo. La misma garantía que en otros lenguajes hay que arrancar con mutexes es aquí una propiedad gratuita del modelo.
Let it crash en lugar de la defensa
En OTP no envuelves cada operación en un bloque defensivo por si hay un fallo. En su lugar dejas que el proceso se caiga, y un árbol de supervisión lo levanta de nuevo en un estado limpio. Es lo contrario de la programación defensiva: no escondes el error, lo dejas volcar un proceso y confías en que la supervisión lo reconstruya.
excache se apoya directamente en esto: la muerte de un proceso de caché no vuelca toda la capa, porque el resto de los procesos vive de forma independiente. El estado corrupto desaparece con el proceso, y su sucesor arranca limpio en lugar de arrastrar datos rotos.
La prueba de esta propiedad consiste en matar deliberadamente un proceso en pleno tráfico y comprobar que la capa sigue respondiendo. Si toda la caché cae con un solo proceso, el árbol de supervisión está mal armado, y una buena prueba lo atrapa enseguida.
Esta es una prueba contrafactual en su forma más pura: no compruebas que el sistema funciona cuando todo va bien, sino que sobrevive al fallo que debe sobrevivir. Una prueba que nunca ve morir un proceso no demuestra ninguna resiliencia.
La resiliencia como propiedad, no como parche
El resultado es una capa que trata el fallo como un estado normal de funcionamiento, no como una excepción que parchear. La concurrencia es segura por diseño, porque nadie comparte memoria, y un fallo aislado sigue siendo local, porque la supervisión solo reconstruye lo que cayó.
Las propiedades de la capa y de dónde brotan
| Propiedad | De dónde brota |
|---|---|
| Sin carreras | un proceso, un mensaje a la vez |
| Sin cerrojos | comunicación por mensajes |
| Aislamiento de fallos | estado encerrado en un proceso |
| Vuelta a un estado limpio | el árbol de supervisión |
Más proyectos
Más trabajos de la misma categoría - mira cómo abordamos retos parecidos.
¿Tiene un proyecto similar?
Escríbenos - el presupuesto es gratuito y llega en una hora.