8 publicaciones etiquetados con "Redis"

Las notificaciones de keyspace son una de las funciones más útiles de Redis y una de las más silenciosamente frágiles. La idea es preciosa: cada vez que se escribe, borra o expira una clave, el servidor publica un evento en un canal pub/sub bien conocido, y cualquiera a quien le interese puede hacer PSUBSCRIBE y reaccionar — invalidar una caché, despertar a un worker, refrescar una proyección. Sin sondeo, sin un GET en bucle preguntando "¿ya ha cambiado?".

La fragilidad está en la letra pequeña. Las notificaciones de keyspace de Redis son pub/sub de disparar-y-olvidar, emitidas por el nodo que procesó el comando, a los suscriptores conectados a ese mismo nodo. En un despliegue en clúster eso significa que un suscriptor solo se entera de las escrituras que aterrizaron en el nodo al que está conectado, y si ese nodo sufre una conmutación por error, la suscripción — y el flujo de eventos que transportaba — se va con él. La función funciona de maravilla en una sola máquina y se vuelve sutil rápidamente en cuanto hay más de una.

Zaris habla exactamente el mismo protocolo — CONFIG SET notify-keyspace-events, los canales __keyspace@0__ y __keyevent@0__, un PSUBSCRIBE corriente desde cualquier cliente de Redis en cualquier lenguaje. Pero la fontanería de debajo no es una reimplementación del notificador de Redis. Es un puente fino hacia una función que Zaris ya tenía: un watch nativo, a nivel de todo el clúster, replicado. Eso cambia lo que valen las notificaciones.

Zaris expone un front-end con protocolo Redis (RESP) para que cualquier cliente Redis, en cualquier lenguaje, pueda apuntar a un clúster de Zaris y usarlo como almacén drop-in. Pero "cualquier cliente Redis" esconde un problema real: los ecosistemas de clientes Redis no se ponen de acuerdo sobre cómo descubrir la topología ni cómo recuperarse cuando un nodo desaparece. Un cliente simple espera un único endpoint estable. Un cliente basado en Sentinel espera preguntarle a un servicio de descubrimiento "¿quién es el master?". Un cliente en modo cluster espera hash slots y redirecciones MOVED/ASK.

Si un almacén hablara solo uno de esos dialectos, toda una clase de clientes quedaría excluida. Por eso el front-end RESP de Zaris admite tres modelos de failover, cada uno acorde a cómo ya espera funcionar una familia concreta de clientes Redis. Eliges el modelo por despliegue; el cliente se comporta exactamente como lo haría contra Redis real.

Una nota honesta de entrada, porque condiciona todo lo que sigue: los tres modelos se sitúan delante del mismo almacén Zaris replicado y particionado. El modelo que elijas cambia la semántica de descubrimiento y redirección — cómo un cliente encuentra un nodo y qué hace cuando uno falla — no dónde reside realmente tu data.

Zaris ya habla en colecciones: hashes, listas, conjuntos y conjuntos ordenados que viven en el servidor y se replican como cualquier otra clave. Los Streams son el quinto tipo, y son el que convierte a Zaris de un almacén en una pieza de infraestructura de mensajería.

Un stream de Zaris es un verdadero registro de solo anexado: las entradas obtienen IDs monótonos, puedes leer rangos y puedes adjuntar grupos de consumidores para que un grupo de trabajadores se reparta el registro entre ellos, haga seguimiento de las entradas pendientes por consumidor y confirme lo que ha procesado. También puedes hacer una lectura bloqueante: un consumidor se detiene y espera a que lleguen nuevas entradas en lugar de iterar en caliente.

Y como es una colección nativa de Zaris, el registro está particionado y replicado exactamente como todo lo demás. Un stream sobrevive a la conmutación por error de un nodo, que es la razón misma para recurrir a la mensajería duradera en primer lugar.

Zaris 1.x almacenaba valores. Zaris 2.0.0 almacena colecciones. Los hashes, listas, conjuntos y conjuntos ordenados son ahora tipos de primera clase, del lado del servidor, con APIs de .NET reales y tipadas y, lo que es igual de importante, se comportan como todo lo demás en el almacén.

Esa última parte es lo que la gente suele entender mal. En muchos sistemas, las "estructuras de datos" son una ilusión del lado del cliente: una biblioteca serializa un diccionario en un blob, lo hace Put y lo llama un hash. Funciona hasta que dos clientes tocan la misma colección a la vez, o hasta que te preguntas qué pasa en una conmutación por error. En Zaris, un hash es un hash en el servidor. Reside en la partición propietaria de su clave, se replica a la réplica de esa partición y sobrevive a la pérdida de un nodo exactamente igual que una clave simple.

Hoy lanzamos Zaris 2.0.0, la mayor versión desde que Zaris alcanzó la disponibilidad general, y la primera con un salto de versión mayor. Convierte a Zaris de un almacén clave/valor rápido y replicado en un servidor completo de estructuras de datos: hashes, listas, conjuntos, conjuntos ordenados, pub/sub y Redis Streams nativos, todos particionados y replicados de la misma forma que ya lo están tus claves.

Y abre la puerta a todos los demás. Cada nodo ahora puede exponer un front-end del protocolo de Redis (RESP), de modo que una aplicación en Python, Ruby, Java, Go —cualquier lenguaje con un cliente de Redis— puede apuntar a Zaris y usarlo como reemplazo directo, sin un SDK nativo y sin reescribir una línea.

El número de versión es un 2, no un 1.x, por una razón: la 2.0.0 cambia el protocolo de cable. Lee la nota de actualización de más abajo antes de implementarlo.

Zaris es un almacén clave/valor distribuido construido de forma nativa para .NET. Sus clientes de primera clase hablan un protocolo binario eficiente y, si tu stack es .NET, esa es la ruta que quieres: APIs asíncronas reales, tipos de .NET, primitivas de coordinación, reemplazos directos de IDistributedCache y HybridCache.

Pero la mayoría de los sistemas no son solo .NET. Hay un servicio en Python haciendo trabajo de datos, un sidecar en Go, un ejecutor de trabajos en Ruby, una pasarela en Node. Reescribir todos ellos sobre un cliente nuevo para probar un almacén nuevo es inviable. Así que, en la 2.0.0, cada nodo de Zaris también puede exponer un listener del protocolo de Redis (RESP2): apunta un cliente de Redis existente a él y usa Zaris como almacén clave/valor de reemplazo directo, en cualquier lenguaje, sin cambiar una sola línea de código del cliente.

Este artículo trata de cómo funciona realmente ese front-end: el modelo de enrutamiento, el modelo de datos, los modelos de conmutación por error y exactamente qué comandos entran y salen.

Redis es rápido. También es, por diseño, monohilo en la ruta de datos: un bucle de eventos, un núcleo, un comando a la vez. Ese es un diseño genuinamente bueno: hace que Redis sea fácil de razonar y elimina toda una categoría de errores de concurrencia. Pero tiene un techo del que no puedes salir a base de dinero. Dale a un motor de un solo bucle de eventos una máquina de 4 núcleos, una de 8 núcleos, una de 32 núcleos, y el rendimiento de lectura acaba en el mismo lugar. Los núcleos extra permanecen inactivos.

Zaris toma el otro camino. Las claves están particionadas y cada partición tiene un propietario, de modo que las lecturas de claves diferentes aterrizan en núcleos diferentes y se ejecutan al mismo tiempo. El resultado es un rendimiento que se mueve cuando añades núcleos: en lugar de una línea plana, una pendiente.

Si tus servicios de .NET ya hablan con Redis, pasar a Zaris no tiene por qué ser una reescritura. Zaris es un almacén clave/valor distribuido, en memoria y replicado, construido de forma nativa para .NET, y desde la versión 2.0.0 habla dos protocolos a la vez: su propio protocolo binario eficiente para clientes de .NET de primera clase, y un front-end RESP2 compatible con Redis al que puede apuntar cualquier cliente de Redis en cualquier lenguaje.

Eso te da dos rutas de migración honestas, y no son mutuamente excluyentes. Puedes empezar con la ruta RESP sin cambios para poner Zaris bajo carga hoy mismo y luego adoptar el cliente nativo donde merezca la pena. Este artículo recorre ambas y te ofrece una regla clara para elegir.