Tom*_*myW 1 transactions redis redis-cluster
我强烈地在线查看,但找不到提供此功能的成熟Redis客户端.才发现这个项目.有人知道Redis客户提供上述服务吗？谢谢.
Redis群集中的事务与Redis Standalone的事务不同.
与客户问题相比,这更像是一个关于担保和权衡的概念问题.
在Redis群集中,特定节点是一个或多个散列槽的主节点,这是在多个节点之间分片数据的分区方案.根据命令中使用的密钥计算的一个哈希槽位于一个节点上.具有多个密钥的命令限于产生相同的散列槽.否则,他们会被拒绝.这种星座称为交叉槽.
事务似乎是执行跨槽密钥命令的解决方案,但在某一点,人们会离开一个节点的范围,并需要另一个节点来继续事务.如果一个密钥存在于一个节点而另一个密钥存在于另一个节点上,则可以是这种情况.仍然没有事务协调,有时可能是Redis Cluster问题的问题.
为Redis Cluster提供事务支持的高级API面临多个问题,目前有两种策略,如何处理Redis集群中的事务:
此选项允许功能完整的交易.客户端库需要跟踪事务执行的节点,并在事务进行时禁止插槽范围之外的密钥.因为插槽只能通过使用包含密钥的命令来确定,所以客户端需要设置事务标志,并且在包含密钥的第一个命令上,需要在事务中的第一个命令之前发出MULTI命令.这里的限制显然要求所有密钥都位于一个节点上.
在这种情况下,在加入分布式事务的所有节点上启动多个事务.该分布式事务可以包括来自所有主节点的密钥.一旦执行了事务,客户端库就会触发事务的执行,库会收集所有结果(以维护命令结果的顺序)并将其返回给调用者.
这种交易方式对客户来说是透明的.一旦请求特定节点上的密钥并且该节点还不是该事务的一部分,MULTI就发出命令以将该节点加入到该事务中.这里的缺点是交易不再是有条件的(WATCH).各个事务不知道密钥是否在不同节点上更改,因此一个事务可以回滚,而其他事务将成功.听起来有点像两阶段提交.
Redis Transactions感觉就像有条件的原子命令批处理一样.重要的是要记住命令执行是延迟的,因为读取结果在事务执行时返回,而不是在发出命令时返回.
对于Redis Cluster,客户尚未决定全球战略.在特定的Redis群集节点上运行事务是安全的,但您只能使用该节点提供的密钥.两种可能的策略都具有可能对某些用例有用但也有限制的属性.
| 归档时间： |
|
| 查看次数： |
1242 次 |
| 最近记录： |