As transações em um Redis Cluster são uma história diferente das transações com o Redis Standalone.
TL;DR;
Isso é mais um problema conceitual em relação a garantias e trade-offs do que uma questão de cliente.
Explicação
No Redis Cluster, um nó específico é um mestre para um ou mais slots de hash, que é o esquema de particionamento para fragmentar dados entre vários nós. Um slot de hash, calculado a partir das chaves usadas no comando, reside em um nó. Comandos com várias chaves são limitados a render ao mesmo slot de hash. Caso contrário, são rejeitados. Essas constelações são chamadas de fenda cruzada.
As transações parecem ser a solução para executar comandos para chaves de slot cruzado, mas em um determinado ponto, sairia do escopo de um nó e precisaria de outro nó para continuar a transação. Isso pode acontecer se uma chave residir em um nó e a outra chave residir em outro nó. Ainda não há coordenação de transações e isso às vezes pode ser um problema para os problemas do Redis Cluster.
Uma API de alto nível que fornece suporte transacional para o Redis Cluster enfrenta vários problemas e há duas estratégias até agora, como lidar com transações no Redis Cluster:
Suporte a transações se todas as chaves estiverem localizadas em um nó
Esta opção permite transações completas. A biblioteca cliente é necessária para acompanhar o nó em que a transação é executada e proibir chaves fora do intervalo de slots durante o tempo em que a transação estiver em andamento. Como o slot só pode ser determinado usando um comando contendo uma chave, o cliente precisa definir um sinalizador transacional e no primeiro comando contendo uma chave o comando MULTI precisa ser emitido, logo antes do primeiro comando dentro da transação. A limitação aqui é claramente o requisito de ter todas as chaves localizadas em um nó.
Transações distribuídas
Nesse caso, várias transações são iniciadas em todos os nós que se unem à transação distribuída. Essa transação distribuída pode incluir chaves de todos os nós mestres. Uma vez que a transação é executada, a biblioteca cliente aciona a execução da transação, a biblioteca coleta todos os resultados (para manter a ordem dos resultados do comando) e os retorna ao chamador.
Este estilo de transações é transparente para o cliente. Assim que uma chave em um nó específico é solicitada e o nó ainda não faz parte da transação, um
MULTI comando é emitido para unir o nó à transação. A desvantagem aqui é que as transações não podem mais ser condicionais (WATCH ). As transações individuais não sabem se uma chave foi alterada em um nó diferente e, portanto, uma transação pode ser revertida enquanto as outras transações seriam bem-sucedidas. Soa um pouco como two-phase-commit. Conclusão
O Redis Transactions parece um lote de comandos atômicos que pode ser condicional. É importante lembrar que a execução do comando é adiada porque os resultados da leitura retornam no momento da execução da transação e não no momento em que o comando é emitido.
Para o Redis Cluster, os clientes não decidiram por uma estratégia global. É seguro executar transações em um nó do Redis Cluster específico, mas você está limitado às chaves atendidas por esse nó. Ambas as estratégias possíveis têm propriedades que podem ser úteis para determinados casos de uso, mas também vêm com limitações.
