ClusterClient with ReadOnly enabled: force read-only operations against primary node

[marcind]

Running github.com/go-redis/redis/v8 at the moment, I have a ClusterClient configured to talk to a Redis cluster (AWS ElastiCache in this case) and it is configured with ReadOnly: true as in general I can retrieve most of the data from replicas.

However, certain read-only commands (such as GET) need to execute against the primary node holding the key to ensure strong consistency semantics in the application. This is particularly problematic when using Pipelines or Transactions.

What's the best way to ensure such behavior. I've explored a few options, but each have downsides:

1. Keep 2 ClusterClient instances, one with ReadOnly: true, the other with ReadOnly: false. This seems like it would double the number of connections and handshake/topology commands against the cluster
2. Use MasterForKey to get the primary node. However, this is somewhat cumbersome to use, and may not work correctly with Pipelined/TxPipelined as it requires knowing the key ahead of time and bypasses the ClusterClient's behavior of grouping the commands by hash slot.
3. Include some innocuous non-readonly command in the pipeline (e.g. SET foo bar XX) to skip the read-only path that allows using replicas. This feels like a hack and won't be obvious to future devs without additional comments/explanation.

Ideally I'd want something like

var c *redis.ClusterClient
c.UseMaster().Get(...)
c.UseMaster().Pipelined(func(...) { ... })

UseMaster here would just return itself if ReadOnly=false, but if ReadOnly=true it would return an instance that suppresses the slotReadOnlyNode selection, e.g. in

go-redis/cluster.go

Lines 1799 to 1802 in 8b2bcd5

	if c.opt.ReadOnly && cmdInfo != nil && cmdInfo.ReadOnly {
	return c.slotReadOnlyNode(state, slot)
	}
	return state.slotMasterNode(slot)

Thoughts?