Las transacciones dentro de un clúster de Redis son una historia diferente a las transacciones con Redis Standalone.
TL;DR;
Eso es más un problema conceptual con respecto a garantías y compensaciones que un problema del cliente.
Explicación
En Redis Cluster, un nodo en particular es un maestro para una o más ranuras hash, ese es el esquema de partición para fragmentar datos entre múltiples nodos. Una ranura hash, calculada a partir de las claves utilizadas en el comando, vive en un nodo. Los comandos con varias claves se limitan a ceder al mismo espacio hash. De lo contrario, son rechazados. Estas constelaciones se denominan ranuras cruzadas.
Las transacciones parecen ser la solución para ejecutar comandos para llaves de ranura cruzada, pero en cierto punto, uno dejaría el alcance de un nodo y necesitaría otro nodo para continuar la transacción. Esto puede ser si una clave vive en un nodo y la otra clave vive en otro nodo. Todavía no hay coordinación de transacciones y eso a veces puede ser un problema para los problemas de Redis Cluster.
Una API de alto nivel que brinda soporte transaccional para Redis Cluster se enfrenta a múltiples problemas y, hasta el momento, hay dos estrategias sobre cómo manejar las transacciones en Redis Cluster:
Admite transacciones si todas las claves están ubicadas en un nodo
Esta opción permite transacciones con todas las funciones. Se requiere que la biblioteca del cliente realice un seguimiento del nodo en el que se ejecuta la transacción y prohíba las claves fuera del rango de ranuras durante el tiempo en que la transacción está en curso. Debido a que la ranura solo se puede determinar mediante un comando que contiene una clave, el cliente debe establecer un indicador transaccional y en el primer comando que contiene una clave, se debe emitir el comando MULTI, justo antes del primer comando dentro de la transacción. La limitación aquí es claramente el requisito de tener todas las claves ubicadas en un nodo.
Transacciones distribuidas
En este caso, se inician múltiples transacciones en todos los nodos que se unen a la transacción distribuida. Esta transacción distribuida puede incluir claves de todos los nodos maestros. Una vez que se ejecuta la transacción, la biblioteca del cliente desencadena la ejecución de la transacción, la biblioteca recopila todos los resultados (para mantener el orden de los resultados del comando) y se los devuelve a la persona que llama.
Este estilo de transacciones es transparente para el cliente. Tan pronto como se solicita una clave en un nodo en particular y el nodo aún no forma parte de la transacción, un MULTI se emite un comando para unir el nodo a la transacción. El inconveniente aquí es que las transacciones ya no pueden ser condicionales (WATCH ). Las transacciones individuales no tienen conocimiento de si se cambió una clave en un nodo diferente, por lo que una transacción podría revertirse mientras que las demás transacciones se realizarían correctamente. Suena un poco como confirmación de dos fases.
Conclusión
Redis Transactions se siente como un lote de comandos atómicos que se puede hacer condicional. Es importante recordar que la ejecución del comando se aplaza porque los resultados de lectura regresan en el momento de la ejecución de la transacción y no en el momento en que se emite el comando.
Para Redis Cluster, los clientes no se han decidido por una estrategia global. Es seguro ejecutar transacciones en un nodo de Redis Cluster en particular, pero está limitado a las claves atendidas por ese nodo. Ambas estrategias posibles tienen propiedades que pueden ser útiles para ciertos casos de uso, pero también tienen limitaciones.
