Vous rencontrerez probablement des résultats malheureux avec une combinaison de pipeline, de transactions (MULTI/EXEC) et de cluster. Dans Redis Cluster, vous parlerez à plusieurs serveurs. Cela a de l'importance ici car les deux commandes de pipeline et MULTI/EXEC sont des commandes orientées sur un seul noeud. Le traitement en pipeline consiste essentiellement à mettre en file d'attente un ensemble de commandes et à les envoyer sous la forme d'un appel réseau unique au serveur. Si vos commandes doivent aller vers des nœuds de cluster différents, cela ne fonctionnera pas car vous ne pouvez pas utiliser un seul envoi réseau pour envoyer à plusieurs nœuds.
De même MULTI ne existe que dans le nœud auquel il a été envoyé, et non à l'échelle du cluster. Ainsi, si vos commandes dans le multi/exec accèdent à des clés sur des nœuds différents, vous n'aurez pas de transactions fiables.
Comment ce manifeste est inconnu car il dépend de la bibliothèque du client et des vérifications qu'il effectue, telles que la façon dont il gère une redirection pendant un bloc de transaction. En fin de compte, cependant, si vous avez absolument besoin d'un multi/exec en pipeline, vous devrez vous assurer que toutes les clés sont sur un nœud en utilisant la méthode "hashtag" de Redis; utiliser le code côté client pour vérifier où se trouvent toutes les clés, en soulevant une erreur si ce n'est pas sur le même nœud tout en espérant qu'une clé n'a pas été déplacée entre la vérification et l'exécution de la commande; ou ne pas utiliser le cluster. Dans les deux premiers cas, vous devez utiliser WATCH pour spécifier les clés à utiliser, ce qui vous permet de détecter un changement d'emplacement et de détecter des conditions de nœud différentes.
Quel est le problème avec l'utilisation de la méthode 'Watch'? Si vous n'aimez pas l'API, 'redigo' est un autre paquet populaire. – JimB