Redis集群中的事务与Redis Standalone的事务不同。

TL; DR;

与客户问题相比，这更多是关于担保和权衡的概念性问题。

说明

在Redis群集中，特定节点是一个或多个哈希槽的主节点，这是在多个节点之间分片数据的分区方案。根据命令中使用的键计算得出的一个哈希槽位于一个节点上。具有多个键的命令被限制为产生相同的哈希槽。否则，它们将被拒绝。这样的星座称为交叉时隙。

事务似乎是执行命令来交叉插入密钥的解决方案，但是在某个时候，一个事务将离开一个节点的范围，并且需要另一个节点来继续事务。如果一个密钥位于一个节点上，而另一个密钥位于另一个节点上，则可能是这种情况。仍然没有事务协调，有时可能是Redis
Cluster问题的问题。

为Redis Cluster提供事务支持的高级API面临多个问题，到目前为止，有两种策略，即如何在Redis Cluster中处理事务：

如果所有密钥都位于一个节点上，则支持交易

此选项允许功能齐全的事务。要求客户端库跟踪事务执行的节点，并在事务进行期间禁止插槽范围之外的键。因为只能通过使用包含密钥的命令来确定插槽，所以客户端需要设置事务标记，并且在包含密钥的第一个命令上，就需要在事务中的第一个命令之前发出MULTI命令。显然，这里的限制是要求所有密钥都位于一个节点上。

分布式交易

在这种情况下，将在加入分布式事务的所有节点上启动多个事务。该分布式事务可以包括来自所有主节点的密钥。一旦执行了事务，客户端库就会触发事务的执行，该库会收集所有结果（以保持命令结果的顺序）并将其返回给调用方。

这种交易方式对客户透明。一旦请求了特定节点上的密钥，并且该节点尚未成为事务的一部分，MULTI就会发出命令将该节点加入事务。这里的缺点是交易不再是有条件的（WATCH）。单个事务不知道密钥是否已在其他节点上更改，因此一个事务可以回滚，而其他事务将成功。听起来有点像两阶段提交。

结论

Redis Transactions感觉就像可以有条件地进行原子命令批处理。重要的是要记住命令执行被延迟，因为读取结果在事务执行时而不是在命令发出时返回。

对于Redis
Cluster，客户尚未决定采用全球战略。在特定的Redis群集节点上运行事务是安全的，但仅限于该节点提供的密钥。两种可能的策略都具有对于某些用例有用的属性，但也有局限性。