feat: add AZ to replica info

[proost]

previous discussion: #710

[rueian]

I think the AZ() is not yet available right after c.connFn. c.connFn only constructs the *mux without making the actual TCP connection. We may need another way to do this.

[rueian]

Oh, I just saw you implemented AZ() as m.pipe(0).AZ() then it would make an actual connection to the server.
But here is still not a good place to call AZ(). It will be better if we call AZ() only when the AZ_AFFINITY is enabled and call it at

rueidis/cluster.go

Line 265 in 09ad427

rIndex := c.opt.ReplicaSelector(uint16(i), g.nodes[1:])

with batching.

[proost]

So, you mean not always set AZ to ReplicaInfo but if user want to know, then set AZ to ReplicaInfo?

[rueian]

I mean the AZ() should be invoked only when necessary, which is when the AZ_AFFINITY is configured.

[rueian]

And, the current calling point, which is right after result.parse, is not a good place to call AZ(). It will always create new connections. We should instead call it after:

rueidis/cluster.go

Lines 232 to 243 in 09ad427

	var removes []conn
	c.mu.RLock()
	for addr, cc := range c.conns {
	if fresh, ok := conns[addr]; ok {
	fresh.conn = cc.conn
	conns[addr] = fresh
	} else {
	removes = append(removes, cc.conn)
	}
	}
	c.mu.RUnlock()

So that we can reuse existing connections as much as possible.

[proost]

69b4018

[rueian]

All the others look good to me. The only thing left is that AZ() itself is too costly. Calling AZ() sequentially could block the refresh for a long time if all the rConn haven't actually connected.

I think we should continue to complete the AZ_AFFINITY feature in this PR so that we can skip AZ() calls when it is not configured on the client. Parallelizing AZ() calls can be another PR.

[proost]

462f2a9

I'm perfectly wrong. How about this?

[rueian]

LGTM, thanks a lot @proost!