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

TL; DR;

这更像是关于担保和权衡的概念性问题，而不是客户问题。

解释

在Redis群集中，特定节点是一个或多个散列槽的主节点，这是在多个节点之间分片数据的分区方案。根据命令中使用的密钥计算的一个哈希槽位于一个节点上。具有多个密钥的命令限于产生相同的散列槽。否则，他们会被拒绝。这种星座称为交叉插槽。

事务似乎是执行跨槽密钥命令的解决方案，但在某一点上，会留下一个节点的范围，并且需要另一个节点来继续事务。如果一个密钥存在于一个节点而另一个密钥存在于另一个节点上，则可以是这种情况。仍然没有交易协调，有时这可能是Redis Cluster问题的一个问题。

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

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

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

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

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

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