英文:
Implementing pipelining and transaction both to a redis cluster using go-redis package without WATCH
问题
我的要求是使用Go语言实现连接到Redis集群的流水线事务。我正在使用go-redis包，该包支持Redis集群、流水线和事务。如何在不使用go-redis包中的WATCH键的情况下实现流水线事务呢？
我还查看了包中的Tx.Pipeline()方法。在实现事务时，是否需要使用WATCH键？
英文:
My requirement is to implement pipelined transactions connecting to a redis cluster using go.I am using go-redis package which supports redis cluster,pipeling and transactions.How do I implement pipelined transactions without using WATCH key in go-redis package.
I also looked at Tx.Pipeline() in the package.Is WATCH key necessary while implementing transaction
答案1
得分: 5
你将可能在使用管道、事务（MULTI/EXEC）和集群的组合时遇到不愉快的结果。在Redis集群中，你将与多个服务器通信。这在这里很重要，因为管道和MULTI/EXEC都是面向单个节点的命令。
管道实质上是将一系列命令排队，并将它们作为单个网络调用发送到服务器。如果你的命令需要发送到不同的集群节点，这种方式将行不通，因为你不能使用单个网络发送命令到多个节点。
类似地，MULTI命令只存在于发送它的节点，而不是整个集群。因此，如果你的multi/exec命令访问不同节点上的键，你将无法进行可靠的事务。
具体表现如何取决于客户端库和其进行的任何检查，例如在事务块期间如何处理重定向。
然而，如果你绝对需要使用管道化的multi/exec，你需要确保所有键都在一个节点上，可以使用Redis的“哈希标记”方法；或者使用客户端代码检查所有键的位置，如果不在同一个节点上则引发错误，同时希望在检查和执行命令之间键不会被移动；或者不使用集群。在前两种情况下，你将希望使用WATCH命令指定要使用的键，从而有机会检测到槽位的变化以及检测到不同节点的条件。
英文:
You will probably experience unhappy results with a combination of pipeline, transactions (MULTI/EXEC), and Cluster. In Redis Cluster you will be talking to multiple servers. This matters here because both pipelining and MULTI/EXEC are single-node oriented commands.
Pipelining is essentially queueing up a bunch of commands and shipping them as a single network call to the server. If your commands need to go to different cluster nodes, that won't work as you can't use a single network send to send to multiple nodes.
Similarly MULTI only exists within the node it was sent to, not cluster-wide. Thus, if your commands in the multi/exec access keys on different nodes, you will not have reliable transactions.
How that manifests is unknown because it depends on the client library and any checks it makes such as how it handles a redirect during a transaction block.
Ultimately, however, if you absolutely need pipelined multi/exec you will either need to ensure all keys are on one node by using Redis' "hashtag" method; use client-side code to check where all the keys are, raising an error if not on the same node while also hoping that a key doesn't been moved between the check and the command execution; or not use cluster. In the first two cases you will want to use WATCH to specify the keys to be used, thus giving you a chance at detecting a slot change as well as detecting different-node conditions.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论