Support for RabbitMQ Clusters about go-rabbitmq HOT 3 OPEN

I am wondering if a resolver interface would be good here

Something like

resolver := ClusterResolver([]string{
	"amqp://usr:[email protected]:5672",
	"amqp://usr:[email protected]:5673",
	"amqp://usr:[email protected]:5674",
})

conn, err := rabbitmq.NewClusterConn(
        resolver,
	rabbitmq.WithConnectionOptionsLogging,
)

Where a resolver is an interface:

type Resolver interface {
   Resolve() ([]string, error)
}

The idea behind this is you could support service discovery for clusters this way. For example you could have ConsulResolver or a SRVResolver for looking up hosts via SRV record in DNS.

Only one implementation should be in the library and would be just a ClusterResovlver

Something lile

type ClusterResolver struct {
   uris []string
   random bool
}

Randomize says that each call to Resolve would shuffle the list.

I am happy to contribute here with a PR if it feels like a good direction?

from go-rabbitmq.

It doesn't look like the base AMQP library supports clustered connections either: streadway/amqp#339

I'm happy to support this if someone wants to open a PR. I believe the implementation should just be that multiple urls can be specified. The first is always used, but on reconnection it just cycles through the list

from go-rabbitmq.

Yeah base library doesn't support reconnects either. With clustering you just need to connect to one of the nodes in the cluster. So on reconnect you would try to (potentially) connect to another server.

So it makes sense that the base AMQP library doesn't support it (if you accept their narrow view of what the library should do).

I believe the implementation should just be that multiple urls can be specified. The first is always used, but on reconnection it just cycles through the list

I agree this should be the base functionality but also why i propose the specifying alternative ways of reconnecting. For me a list is no good as the backend systems are going to be dynamic (think kubernetes) and needs to be accessed via service discovery.

This is similar to the HostProvider in the go-zookeeper/zk although much simpler. I think the "hostprovider" or whatever it should me named just always return a list to cycle through on each reconnect.

I do think that a single implementation of this should be in this library with other implementations could be provided by the caller unique to their environment.

from go-rabbitmq.