是否有任何Redis客户端(首选Java)支持Redis集群上的事务?

我集中精力查看在线,但是找不到提供此功能的成熟Redis客户端。只发现了这个项目。任何人都知道Redis客户提供上述内容吗?谢谢。

回答:

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

TL; DR;

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

说明

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

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

Cluster问题的问题。

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

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

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

分布式交易

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

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

回答:

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

对于Redis

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

以上是 是否有任何Redis客户端(首选Java)支持Redis集群上的事务? 的全部内容, 来源链接: utcz.com/qa/405192.html

回到顶部