What Are They?

Redis has two primary categories of running multiple instances. There is “standard replication” and coming soon “Redis Cluster”. To manage Replication you use Sentinel. Cluster mostly manages itself but you can combine the two for extended, if complex, HA+Replication.

This guide will walk you through each in order to develop a better understanding of the differences and use cases for each. We will begin with Redis Cluster. Note that at the time this guide is being written, Cluster is not yet in a production release and details may change.

Redis Cluster

Redis Cluster is primarily a means of sharding data across multiple instances automatically. It is due out in Redis 3.0.

What it Does

Cluster is Redis which is configured to spread data across a given number of Redis instances. To manage what data is where, Cluster has a protocol spec which allows clients to talk to any master in the cluster. If the key being operated on is stored locally the data is returned as normal.

However, if the data is stored on a different node a MOVED response is returned telling the client which master to talk to instead. This mechanism thus requires client-side support for the cluster

Note that Cluster does not provide HA or replication directly.

What Cluster Is For

The use cases for Cluster evolve around either spreading out load (specifically writes) and surpassing single-instance memory capabilities. If you have 2T of data, do not want to write sharding code in your access code, but have a library which supports Cluster then you probably want Redis Cluster. If you have a high write volume to a wide range of keys and your client library supports Cluster, Cluster will also be a good fit.

Redis Sentinel

Redis supports multiple slaves replicating data from a master node. This provides a backup node which has your data on it, ready to serve data. However, in order to provide automated failover you need some tool. For Redis this tool is called Sentinel. In this document we will use the term “pod” to describe a Redis master with one or more slaves; this avoids confusion with the term “cluster”.

What it Does

Sentinel is configured to point to a master you need managed. It will then query the master for all connected slaves. Once it has determined the configuration of the pod it will proceed to monitor each node and upon confirmation of a down master it will promote a slave and reconfigure each slave to point to the new master.

In order to use this for transparent client connection management you will need to either put the master node behind a Virtual IP or a load balancer which knows, or can be dynamically configured, which node is the master.

The other option is to use a client which has implemented Sentinel support.

Sentinel uses a voting+quorum mechanism so you need at least three Sentinel nodes working together. I refer to this as a Sentinel constellation. Each pod is given a name in the Constellation. This provides an additional capability if using Sentinel-capable client code. In this scenario you can use Sentinel for service discovery.

What is is for

The standard use case for Sentinel is a single master with 1-2 slaves ready to be promoted. Sentinel is then used to keep one node handling data traffic at all times, within limits of aliveness-testing.

Alternatively, one could deploy a single Sentinel and have each standalone master or each pod connect to it to provide service discovery. In this scenario perhaps you have a “webcache” instance and a “metrics” instance. With appropriate client side support your applications would connect to the Sentinel instance and get the connection information for either “webcache” or “metrics” without needing unique connection information for each client.

Which To Use

If your memory requirements exceed system memory or you need to distribute writes across multiple node to maintain performance levels, Redis Cluster is where you should be looking.

If you are looking for high-availability, you’ll want to look more into deploying Sentinel.

Additional Reading
• Using Sentinel

Tags: sentinel cluster