6 publicaciones etiquetados con "Patrones Distribuidos"

La mayor parte de este blog ha profundizado en una cosa a la vez: compare-and-swap, transacciones multiclave, estructuras de datos nativas, streams, watch, el op-log que hay debajo. Cada artículo responde a "cómo funciona esto". Este responde a una pregunta distinta y más práctica: cuando tienes un problema delante, ¿cuál eliges?

Esa pregunta importa porque la elección equivocada rara vez es un fallo estrepitoso. Es un sistema que funciona en la demo y luego pierde una actualización bajo carga, o canaliza a mil escritores a través de una sola clave, o usa una notificación de tipo "dispara y olvida" donde hacía falta un log durable. Las primitivas no te impiden usarlas mal. Así que esto es una guía de campo: el modelo mental que las une, una tabla de decisión, un recorrido por cada rama con su encaje honesto y su límite honesto, y un diagrama de flujo al final.

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.

Un post complementario, Coordinación sin carreras sobre CAS optimista, argumentaba que una única primitiva — una versión propiedad del almacén más una escritura condicional guardada por versión — lleva una cantidad notable de coordinación. También trazó una línea dura: el CAS es atómico sobre una clave. Mueve dinero de la cuenta A a la cuenta B y un único compare-and-swap no puede cubrir ambas; el consejo honesto fue modelar la transferencia como una máquina de estados sobre una clave, o recurrir a una saga.

Esa línea es real, pero no es toda la historia. Zaris tiene una genuina transacción multiclave — BeginTransactionAsync, un conjunto de lectura/escritura preparado, CommitAsync — y hace commit a través de claves y a través de nodos con una garantía de todo-o-nada. Este post trata de lo que esa transacción realmente es por debajo (un commit de dos fases coordinado por el cliente sobre versiones optimistas), de lo que garantiza exactamente, y de la única sutileza que decide si tu invariante entre claves realmente se mantiene.

Es tentador juzgar un almacén de datos por la longitud de su lista de comandos. Redis tiene INCR, SETNX, MULTI/EXEC, WATCH, Lua, SCAN, pub/sub: un verbo para cada ocasión. El cliente .NET de Zaris, en cambio, parece casi austero. No hay incremento atómico del lado del servidor. No hay una transacción general multiclave que ejecute lógica arbitraria. No hay escaneo por prefijo. El pub/sub nativo existe únicamente a través del front-end RESP, no del cliente .NET tipado.

Lo que el cliente .NET te da en su lugar es una primitiva de coordinación pequeña y afilada: compare-and-swap optimista versionado. Esta publicación trata de hasta dónde llega realmente esa única primitiva, porque la respuesta honesta es: sorprendentemente lejos. Un limitador de tasa, una cartera que nunca queda en negativo bajo mil débitos concurrentes, una cola de trabajos donde exactamente un worker reclama cada trabajo, y un conjunto de reglas de feature flags que nunca pierde una actualización bajo ediciones concurrentes de administradores. Todos ellos, a partir de la misma primitiva, sin maquinaria adicional del lado del servidor.

Aquí hay un hecho sobre cualquier almacén clave-valor particionado que los diagramas pulidos tienden a omitir: el nodo que posee tu clave se moverá. Un nodo falla y sus particiones conmutan por error a sus réplicas. Escalas horizontalmente y las particiones migran al nuevo miembro. Un primario preferido vuelve y la propiedad conmuta de vuelta a él. Cada uno de esos eventos significa que el nodo con el que tu cliente hablaba felizmente hace un milisegundo es, en este momento, el nodo equivocado para algún conjunto de claves.

La experiencia ingenua del cliente en ese momento es fea: un reinicio de conexión, un genérico "error de servidor" o —peor— una escritura que aterriza en un nodo que ya no es el dueño activo y silenciosamente no va a ninguna parte. El cliente .NET de Zaris está construido para que nada de eso llegue a tu código. Un cambio de propiedad se convierte en un estado tipado, el cliente reencamina al nuevo dueño, y el reintento está acotado tanto por un presupuesto de intentos como por una fecha límite de reloj de pared. En el caso común, tu PutAsync simplemente tarda unos milisegundos más y devuelve Ok. Esta publicación trata de la maquinaria que hace que eso sea cierto y —no menos importante— de los casos que deliberadamente no disimula.

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.