Saltar al contenido principal

Si vienes de Redis: apunta tu aplicación .NET a Zaris

· 6 min de lectura
Clustron Team
Clustron Team
Ingeniería de Sistemas Distribuidos

Dos rutas de Redis a Zaris

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.

Ruta A — conserva tu cliente de Redis​

La forma más rápida de probar Zaris es no cambiar tu código en absoluto. Habilita el listener RESP en tus nodos de Zaris y apunta tu cliente de Redis existente al puerto RESP de un nodo. Zaris acepta comandos de Redis ordinarios, enruta cada uno a la partición propietaria de la clave y responde por el mismo canal que tu cliente ya entiende.

Aquí está StackExchange.Redis hablando con Redis:

var mux = await ConnectionMultiplexer.ConnectAsync("redis-0:6379");
var db  = mux.GetDatabase();

await db.StringSetAsync("session:42", payload, TimeSpan.FromMinutes(30));
var back = await db.StringGetAsync("session:42");

Y aquí está el mismo código contra Zaris: lo único que cambia es el host:

var mux = await ConnectionMultiplexer.ConnectAsync("zaris-0:6379");
var db  = mux.GetDatabase();

await db.StringSetAsync("session:42", payload, TimeSpan.FromMinutes(30));
var back = await db.StringGetAsync("session:42");

Ningún paquete nuevo, ningún cambio de API. Bajo el capó, Zaris aplica el hash a las claves con el mismo cálculo de slot CRC16(key) % 16384 que usa Redis Cluster, de modo que un cliente consciente del clúster enruta cada clave directamente al nodo que la posee: sin proxy, sin saltos adicionales, igual que Redis Cluster. (Detrás de un balanceador de carga simple o de Sentinel, cualquier nodo aceptará cualquier clave en su lugar.) Si quieres los detalles de cómo funciona eso y cómo se comporta la conmutación por error, consulta cómo Zaris habla el protocolo de Redis y la referencia del protocolo de Redis.

Qué vigilar en esta ruta:

  • Solo RESP2. El front-end habla RESP2, así que fija tu cliente de Redis a versiones que negocien RESP2 y no asuman marcos push de RESP3.
  • Algunos comandos se rechazan limpiamente, no se simulan. Lua/EVAL, geo, HyperLogLog, bitmaps y la persistencia RDB/AOF no están implementados: Zaris devuelve un claro "no soportado" en lugar de fingir. El desglose completo de lo que funciona está en la matriz de compatibilidad de comandos de Redis, medida frente a StackExchange.Redis 2.8.16: aproximadamente 126 comandos soportados, 92 no soportados limpiamente, cero sorpresas.
  • Los comandos de coordinación que realmente usas están ahí. MULTI/EXEC se asignan a las transacciones nativas de confirmación en dos fases de Zaris, SET key val NX PX te da el patrón de bloqueo distribuido, y las notificaciones de espacio de claves funcionan.

Esta ruta es ideal cuando un servicio es políglota, cuando Redis es compartido entre equipos, o cuando simplemente quieres tener Zaris funcionando en staging esta misma tarde.

Ruta B — el cliente nativo de .NET​

Una vez que Zaris demuestra su valía, el cliente nativo es donde las aplicaciones orientadas a .NET le sacan el máximo partido. No es un envoltorio de protocolo: es un cliente de .NET real con APIs tipadas, y sus operaciones de la ruta rápida (Get/Put/Delete/Expire/Persist/TTL) devuelven ValueTask, de modo que no asignan nada cuando se completan de forma síncrona.

La adopción es mayormente configuración. Si usas ASP.NET Core y Redis como tu IDistributedCache, el cambio son dos líneas:

// Program.cs
builder.Services.AddClustronZaris("cache", "zaris://cache-0:7861,cache-1:7861/app");
builder.Services.AddClustronDistributedCache("cache");

// ...then inject IDistributedCache (or HybridCache) and use it exactly as before.

Las cadenas de conexión son las mismas en todas partes: en proceso, remotas, en Docker o en Kubernetes:

zaris://host:7861/store

Usa zariss:// para TLS, separa con comas los hosts semilla para la conmutación por error y suministra los tokens de forma segura con env: o file: en lugar de en línea.

Más allá de la caché, el cliente nativo te ofrece cosas que la API de Redis simplemente no modela como operaciones de primera clase: hashes, listas, conjuntos, conjuntos ordenados y Streams tipados; compare-and-swap; operaciones masivas y por lotes; consultas de escaneo y de prefijo; y un conjunto completo de primitivas de coordinación: transacciones, bloqueos distribuidos, elección de líder, concesiones, contadores, limitación de tasa y una cola de trabajos. Si has estado ensamblando todo eso a partir de los bloques de construcción de Redis y de Lua, aquí son nativos.

Cuándo elegir cuál​

Una regla sencilla:

  • Opta por la Ruta A (RESP) cuando el llamante no es .NET, cuando Redis es compartido entre servicios, o cuando quieres la prueba más rápida posible sin ningún cambio de código.
  • Opta por la Ruta B (nativa) cuando el servicio es .NET, cuando te importa el rendimiento sin asignaciones, o cuando quieres estructuras de datos tipadas y primitivas de coordinación en lugar de patrones hechos a mano.

La mayoría de los equipos acaban con una mezcla —RESP para los bordes políglotas, nativo para el núcleo de .NET— y ese es un estado final perfectamente bueno, no una migración a medias.

Una nota sobre la actualización​

Zaris 2.0.0 es una versión mayor con una ruptura del protocolo de cable en el cliente nativo: el enrutamiento del clúster pasó a un hashing alineado con CRC16, y el mínimo del protocolo es ahora 2. Un servidor 2.0.0 rechaza a los clientes anteriores a 2.0 en el HELLO, así que actualiza tus clientes nativos y servidores juntos. El front-end RESP no se ve afectado: los clientes de Redis no participan en absoluto en el protocolo nativo. La historia completa está en el anuncio de la 2.0.0.

Primeros pasos​

dotnet add package Clustron.Zaris.SDK --version 2.0.0

Si tu stack es .NET y has estado ejecutando Redis sobre todo porque era la elección obvia, Zaris te permite conservar todo lo que funciona hoy y adoptar la integración nativa a tu propio ritmo.