![\"Mascote](\"\/wp-content\/uploads\/2026\/09\/keydb-fork-multithread-redis.webp\")
<\/p>\n<\/p>\n
KeyDB naci\u00f3 con una promesa sencilla: tomar Redis, que ejecuta los comandos en un \u00fanico hilo, y hacer que use todos los n\u00facleos de la m\u00e1quina. Funcion\u00f3, se convirti\u00f3 en producto, fue comprado por Snap y gan\u00f3 caracter\u00edsticas que Redis nunca tuvo, como la replicaci\u00f3n activa entre dos maestros y la expiraci\u00f3n de miembros dentro de un conjunto. Sin embargo, en septiembre de 2026 la \u00faltima versi\u00f3n de KeyDB tiene casi tres a\u00f1os. Antes de poner KeyDB en producci\u00f3n, conviene saber qu\u00e9 hace bien, qu\u00e9 se rompe y en qu\u00e9 estado est\u00e1 el proyecto. Este post instala, configura, replica y mide KeyDB en contenedores, y termina con una recomendaci\u00f3n.<\/p>\n
KeyDB empez\u00f3 a principios de 2019 como un experimento de John Sully<\/strong> e Ben Schermel<\/strong>, en Toronto, para a\u00f1adir multithreading a Redis. El proyecto creci\u00f3, pas\u00f3 por Y Combinator (promoci\u00f3n del verano de 2020) y se convirti\u00f3 en la empresa EQ Alpha Technology, que manten\u00eda dos ediciones: la abierta y KeyDB Pro, cerrada y de pago.<\/p>\n En 12 de mayo de 2022<\/strong> KeyDB anunci\u00f3 que pasaba a formar parte de Snap<\/a>, propietaria de Snapchat. Con la compra, el c\u00f3digo de la edici\u00f3n Pro se abri\u00f3 y la versi\u00f3n 6.3.0 fusion\u00f3 todo en un \u00fanico proyecto bajo licencia BSD-3-Clause<\/strong>. El repositorio pas\u00f3 de O motivo declarado do fork est\u00e1 no README: os autores achavam que o Redis priorizava a simplicidade do c\u00f3digo em detrimento da simplicidade para o usu\u00e1rio, que acabava precisando de componentes externos (Sentinel, proxies, scripts) para resolver problemas comuns. O KeyDB quis ser o Redis “com pilhas inclu\u00eddas”, mantendo compatibilidade com o protocolo, os m\u00f3dulos e os scripts Lua.<\/p>\n El Redis cl\u00e1sico ejecuta todos los comandos en un hilo principal. Desde la versi\u00f3n 6 puede usar En la pr\u00e1ctica, esto se controla mediante dos directivas en el El README recomienda relacionar El diagrama muestra los dos nodos usados en el laboratorio de este post, cada uno con cuatro hilos, y la replicaci\u00f3n activa entre ellos:<\/p>\n Seg\u00fan la documentaci\u00f3n oficial<\/a>, KeyDB a\u00f1ade al conjunto de funcionalidades de Redis:<\/p>\n Consult\u00e9 GitHub, Docker Hub y el repositorio APT del proyecto el 23 de septiembre de 2026:<\/p>\nEQ-Alpha\/KeyDB<\/code> para Snapchat\/KeyDB<\/a>, y Snap comenz\u00f3 a utilizar KeyDB en parte de su propia capa de cach\u00e9.<\/p>\nC\u00f3mo funciona la arquitectura multihilo<\/h2>\n
io-threads<\/code> para leer y escribir en los sockets en paralelo, pero la ejecuci\u00f3n de los comandos sigue siendo serializada. KeyDB fue por otro camino: ejecuta el bucle de eventos completo en varios hilos<\/strong>. Cada conexi\u00f3n se asigna a un hilo en el accept()<\/code>, y el parsing y la E\/S de red ocurren en paralelo. El acceso a la tabla de claves est\u00e1 protegido por un spinlock<\/strong>, y las transacciones mantienen ese bloqueo durante todo el EXEC<\/code>, lo que preserva la atomicidad que las aplicaciones esperan de Redis (explicaci\u00f3n de los autores<\/a>).<\/p>\nkeydb.conf<\/code>:<\/p>\nserver-threads 4 # threads que atendem clientes (padr\u00e3o do pacote: 2)\nserver-thread-affinity true # fixa cada thread num n\u00facleo<\/code><\/pre>\nserver-threads<\/code> al n\u00famero de colas de la placa de red, no al n\u00famero de n\u00facleos, y sugiere 4 como punto de partida: como KeyDB usa spinlocks, demasiados hilos aumentan la contenci\u00f3n por el lock. En el benchmark m\u00e1s abajo, 8 hilos a\u00fan rindieron m\u00e1s que 4 con 6 n\u00facleos dedicados al servidor, as\u00ed que mide en tu propio hardware.<\/p>\n![\"Diagrama](\"\/wp-content\/uploads\/2026\/09\/keydb-arquitetura-replicacao-ativa.webp\")
<\/figure>\nCaracter\u00edsticas que Redis no tiene<\/h2>\n
\n
EXPIREMEMBER<\/code> da TTL a un miembro de set, hash o sorted set, no a la clave entera. En Redis, esta funcionalidad solo lleg\u00f3 en la versi\u00f3n 7.4, y \u00fanicamente para campos de hash.<\/li>\nKEYS<\/code> e SCAN<\/code> sin bloquear la base de datos, y un background save<\/em> sin fork()<\/code>, que evita la duplicaci\u00f3n de p\u00e1ginas de memoria durante la instant\u00e1nea.<\/li>\nstorage-provider flash \/caminho<\/code>, KeyDB lo escribe todo en un RocksDB en SSD\/NVMe y mantiene en RAM solo los datos calientes. La propia documentaci\u00f3n<\/a> clasifica la funci\u00f3n como beta\/experimental<\/strong>.<\/li>\ndb-s3-object<\/code>, y ModJS<\/strong>, un m\u00f3dulo para escribir comandos en JavaScript sobre V8.<\/li>\n<\/ul>\nLa situaci\u00f3n del proyecto en septiembre de 2026<\/h2>\n