AWS Redis - Cluster mode enabled/disabled. How does it distribute traffic?

Question

We recently chose to use Amazon elastic cache redis in our application, while going through the documentation some things are not clear.

1) Cluster mode disabled cluster for Redis has Primary endpoint in the AWS console of cluster, when we connect to primary endpoint with jedis client, does this primary endpoint distribute the read traffic to the read replicas of the cluster? or the application explicitly have to connect to read replicas in the cluster? Eg. Jedis client

2) Cluster mode enabled for redis has Configuration endpoint in the AWS console of Redis, so when we connect to this Configuration endpoint with a client does the configuration endpoint distribute the write and read traffic between the shards in the cluster? or the application has to connect to each shard explicitly using JedisCluster object passing the shard's primary endpoint?

3) For Cluster mode enabled for Redis, how does the elastic cache split the keys across shards?

Answer 1

Just noticed from the link: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Endpoints.html, it looks like you can use their https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Endpoints.html#Endpoints.Find.CLI.ReplGroups and discover the actual endpoints and treat them like regular shard/replica nodes, or use their endpoints:

Redis standalone node, use the node's endpoint for both read and write operations.

Redis (cluster mode disabled) clusters, use the Primary Endpoint for all write operations. Use the Reader Endpoint to evenly split incoming connections to the endpoint between all read replicas. Use the individual Node Endpoints for read operations (In the API/CLI these are referred to as Read Endpoints). Blockquote

So, looks like the primary endpoint will act as a proxy and reader endpoint does the same plus some loadbalancing including routing the keys to the right shard based on the key. Read clients will only connect to one endpoint.

Redis (cluster mode enabled) clusters, use the cluster's Configuration Endpoint for all operations. You must use a client that supports Redis Cluster (Redis 3.2). You can still read from individual node endpoints (In the API/CLI these are referred to as Read Endpoints).

Same as before, but uses a single endpoint for reads and writes. This is probably done to make it transparent the availability and failoever if something happens.

Answer 2

Looks like in cluster aware clients, if the client is smart enough, it can use the configuration endpoint to discover all masters/slaves and then it is up to you to connect and maintain them so such cluster aware clients do have some options:

1. call cluster slots command on any seed node, in this case, the coordinator node and discover entire topology https://redis.io/commands/cluster-slots
2. call any endpoint, get a MOVED response back if they query or select from a wrong node with an invalid hash that does not belong to that node: https://redis.io/topics/cluster-spec clients may be redirected to other nodes using redirection errors -MOVED and -ASK. The client is in theory free to send requests to all the nodes in the cluster, getting redirected if needed, so the client is not required to hold the state of the cluster. However clients that are able to cache the map between keys and nodes can improve the performance in a sensible way.

Once the toplogy is discovered, the slot ownership information about which master owns which slot partition, the clients can choose a standard CRC hash to find the slot and go to that node directly.