transactions - 是否有任何 Redis 客户端（首选 Java）支持 Redis 集群上的事务？

Question

我在网上搜索了很多，但找不到提供此功能的成熟 Redis 客户端。只找到了这个项目。有人知道提供上述内容的 Redis 客户端吗？谢谢你。

score 6 · Accepted Answer

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

TL;博士;

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

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

事务似乎是执行跨槽键命令的解决方案，但在某一时刻，一个人会离开一个节点的范围，需要另一个节点来继续事务。这可能是一个密钥存在于一个节点上，而另一个密钥存在于另一个节点上。仍然没有事务协调，这有时可能是 Redis Cluster 的问题。

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

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

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

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

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

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