Les transactions au sein d'un cluster Redis sont une histoire différente de la transaction avec Redis Standalone.
TL;DR;
Il s'agit plus d'un problème conceptuel concernant les garanties et les compromis que d'un problème client.
Explication
Dans Redis Cluster, un nœud particulier est un maître pour un ou plusieurs emplacements de hachage, c'est le schéma de partitionnement pour partager les données entre plusieurs nœuds. Un emplacement de hachage, calculé à partir des clés utilisées dans la commande, vit sur un nœud. Les commandes avec plusieurs clés sont limitées pour céder au même emplacement de hachage. Sinon, ils sont rejetés. De telles constellations sont appelées fentes croisées.
Les transactions semblent être la solution pour exécuter des commandes sur des clés inter-slots, mais à un certain moment, on quitterait la portée d'un nœud et aurait besoin d'un autre nœud pour continuer la transaction. Cela peut être le cas si une clé réside sur un nœud et que l'autre clé réside sur un autre nœud. Il n'y a toujours pas de coordination des transactions et cela peut parfois être un problème pour les problèmes de Redis Cluster.
Une API de haut niveau fournissant une prise en charge transactionnelle pour Redis Cluster est confrontée à plusieurs problèmes et il existe jusqu'à présent deux stratégies pour gérer les transactions dans Redis Cluster :
Prend en charge les transactions si toutes les clés sont situées sur un nœud
Cette option permet des transactions complètes. La bibliothèque cliente doit garder une trace du nœud sur lequel la transaction est exécutée et interdire les clés en dehors de la plage d'emplacements pendant la durée de la transaction. Étant donné que l'emplacement ne peut être déterminé qu'en utilisant une commande contenant une clé, le client doit définir un indicateur transactionnel et à la toute première commande contenant une clé, la commande MULTI doit être émise, juste avant la première commande dans la transaction. La limitation ici est clairement l'exigence d'avoir toutes les clés situées sur un nœud.
Transactions distribuées
Dans ce cas, plusieurs transactions sont lancées sur tous les nœuds qui rejoignent la transaction distribuée. Cette transaction distribuée peut inclure des clés de tous les nœuds maîtres. Une fois la transaction exécutée, la bibliothèque cliente déclenche l'exécution de la transaction, la bibliothèque collecte tous les résultats (pour maintenir l'ordre des résultats de la commande) et les renvoie à l'appelant.
Ce style de transactions est transparent pour le client. Dès qu'une clé sur un nœud particulier est demandée et que le nœud ne fait pas encore partie de la transaction, un MULTI La commande est émise pour joindre le nœud à la transaction. L'inconvénient ici est que les transactions ne peuvent plus être conditionnelles (WATCH ). Les transactions individuelles ne savent pas si une clé a été modifiée sur un nœud différent, et donc une transaction pourrait être annulée tandis que les autres transactions réussiraient. Cela ressemble un peu à une validation en deux phases.
Conclusion
Redis Transactions ressemble à un traitement par lots de commandes atomiques qui peut être rendu conditionnel. Il est important de se rappeler que l'exécution de la commande est différée car les résultats de lecture sont renvoyés au moment de l'exécution de la transaction et non au moment où la commande est émise.
Pour Redis Cluster, les clients n'ont pas décidé de stratégie globale. Il est sûr d'exécuter des transactions sur un nœud de cluster Redis particulier, mais vous êtes limité aux clés servies par ce nœud. Les deux stratégies possibles ont des propriétés qui pourraient être utiles pour certains cas d'utilisation, mais elles présentent également des limites.
