Monkey

But doing so deviates from your expected setup; it won't look for nodes that are closer to itself, it will only randomly select a node.

I've recently been reflecting on the request flow in redis-cluster. It seems that we shouldn't randomly select another node to execute commands when all the nodes corresponding to a hash...

@vmihailenco Do you understand why we choose a random node?

@vmihailenco @ofekshenawa view?

I am in favor of canceling the random selection of nodes because there seems to be no clear evidence that a migration has occurred in the Redis cluster; it is...

> @monkey92t It looks like the other authors haven't responded yet. It is greatly appreciated if its possible for you to take ownership of this issue and review the PR...

If no usable nodes are available, we can randomly choose a node responsible for that hash slot. If a fixed node is selected, go-redis might attempt TCP connections, which could...

A better solution might be to use goroutines to continuously ping the lost nodes and mark them as RUNNING when access is restored. If there are any access requests during...

Yes, your idea is not wrong, but it carries a significant risk. If node A goes down and many subsequent requests still use node A, it will send many TCP...

This feels complicated, but `net.Conn` is hard to be controlled by `ctx`. `net.Conn` uses `Deadline` instead of `ctx`... ```go var conn net.Conn // go-redis pool.Conn ctx := context.Background() processBlockCmd :=...