Feat: Adding availability zone to ReplicaInfo.

[proost]

Summary

Adding AZ description to ReplicaInfo . We cover [valkey client spec](https://github.com/valkey-io/valkey-doc/pull/164/files/538267853f1de1265c28b9a1790aa95e133f15b5#diff-2bfc9a970925d3653728ad770a3ff03d65be3b8e4edf70835f849b4a60d80f5f)

Design

Adding AZ method to wire .

type wire interface {

	...
	
	AZ() string
}

Also adding az field to pipe.

type pipe struct {
	

	...
	
	az string
	
	...
	
}

AZ method returns connected valkey server’s availability zone.

We already send HELLO command in _newPipe constructor if using RESP3 protocol. Unless user don’t want to use RESP3 protocol or Redis version is lower than 6, we can get availability_zone from HELLO command if Valkey server supports availability_zone.

Unless Redis version is lower than 6, we send HELLO command always using RESP2 protocol. Unless noHello error message is matched, we can parse “availability_zone” and “version” from HELLO command response.

After parsing availability_zone value, we store as az field value.

type conn interface {

  ...
  
	AZ() string
}

Because we can’t directly access to wire in clusterClient . we add AZ method to conn like Version or Info methods. AZ method is just proxy to call AZ method in wire

Adding AZ to ReplicaInfo

type ReplicaInfo struct {
	Addr string
	AZ string
}

In _refresh method, we should two things.

1. after each conn is constructed, we call AZ() to get server’s availability zone.
2. set availability zone each ReplicaInfo in group

[rueian]

I can’t predict what it will look likeLowestLatency replica spec. I weakly guess

1. using elapsed time of making a connection like lettuce did.
2. using server’s stats.

I guess it should be the first one since a server’s stats can't provide client latencies.

we send INFO server command in _newPipe constructor. Because we can obtain valkey server’s availability zone from Server section in INFO according to valkey code.

That is the only way to obtain the availability zone right now. However, it seems overkill to me. I think we should propose letting the HELLO response carry the availability zone as well so that we don't need to send an additional INFO command.

[rueian]

Valley 8.1 will respond availability_zone in HELLO response! No need to use an additional INFO command.

Here is also a guide for this AZ_AFFINITY feature on glide: https://valkey.io/blog/az-affinity-strategy/

[rueian]

Hi @proost, would you like to work on this?

[proost]

@rueian
Yes, Of course. I'm waiting for your PR to be merged. I will update this proposal soon.

[proost]

@rueian
I updated the proposal. can you review again?

[rueian]

LGTM. And I think we don’t need to support the cases where we can’t get the az from HELLO now.

[proost]

#721