What is the difference between:Redis Replicated setup, Redis Cluster setup Redis Sentinel setup and Redis with Master with Slave only?[REDISSON]

Question

I've read https://github.com/redisson/redisson

And I found out that there are several

• Redis Replicated setup (including support of AWS ElastiCache and Azure Redis Cache)
• Redis Cluster setup (including support of AWS ElastiCache Cluster and Azure Redis Cache)
• Redis Sentinel setup
• Redis with Master with Slave only

I am not a big expert in clusters and I don't understand the difference between these setups.

Could you beiefly explain the differences ?

Answer 1

Disclaimer I am an AWS employee.

I do not know how Redis Replicated Setup is different from Redis in Master-Slave mode. Maybe they mean cross-region replication?

In any case, I can try and explain setups I know about:

1. Redis with Master with Slave only - is a single shard setup where you create a primary replica together with one or more secondary (slave) replicas (let's hope PC police won't arrest me). This setup is used to improve the durability of your in-memory store. It's not advised to use your secondaries for reads because such setup has eventual consistency guarantees and your replica reads may be stale (depending on the replication lag).
2. Redis Cluster setup - the setup supported by cloud provides such as AWS Elasticache. In this setup your workload can be spread horizontally across multiple shards and each shard may have its own secondary replicas. Your client library must support this setup since it requires maintaining multiple connections to several nodes at a client level. Moreover, there are some locality rules you need to follow in order to use cluster mode efficiently:
   • Keys with foo{<shard>}bar notation will be routed to their shard according to what is stored inside curly brackets.
   • You can not use mset, mget and other multi-key commands across shards. You can still use these commands if their keys contain the same {shard} part.
   • There are additional cluster mode admin commands that are exposed by Redis but they are usually hijacked and hidden from users by cloud providers since cloud provides use them in order to manage redis cluster themselves.
   • Redis cluster have an ability to migrate part of your workload between shards. However, it still obliged to preserve correctness with respect to {shard} notation. Since your client library is responsible to fetch data from specific shard it must handle "moved" response when a shard might redirect it to another node.
3. Redis Sentinel setup - using an additional server that provides service discovery functionality for Redis clusters. Not strictly required and I believe is less popular across users. It serves as a single source of truth regarding each node's health and state. It provides monitoring, management, and service discovery functions for managing your Redis cluster. Many Redis client libraries provide the option of connecting to Redis sentinel nodes in order to achieve automatic service discovery and seamless failover flow. One of the reasons why this setup is less popular is because cloud companies like AWS Elasticache provide this service out of the box.