Redis Sentinel vs Redis Cluster: Failover Design

Both Redis Sentinel and Redis Cluster provide automatic failover, and choosing the wrong one costs either scalability you need or complexity you do not. Sentinel wraps a single primary with replicas and gives you a highly available cache-sized dataset with a stable, familiar data model. Cluster shards the keyspace across primaries and gives you horizontal scale, at the cost of multi-key operations that must stay within a slot, more moving parts, and a client that understands redirection. This article compares the two across the dimensions that actually decide deployments: data size, failover mechanics, client behaviour and operational risk.

What each one actually is

Sentinel is a separate process that monitors Redis instances, reaches agreement with other Sentinels about whether a primary is truly down, and promotes a replica. It does not configure Redis; it tells your client — or your proxy — where the current primary is. The canonical deployment uses three or five Sentinel processes on separate hosts, monitoring one primary and its replicas.

Cluster is a distributed Redis: the keyspace is divided into 16384 hash slots, each owned by a primary, with replicas per primary. Nodes gossip about slot ownership and cluster state, clients are redirected to the node holding the slot, and multiple primaries can accept writes at once.

Sentinel: quorum, safety, and where to run it

Sentinel guarantees two properties worth understanding precisely. The liveness property: if a majority of Sentinels can talk to each other, one will eventually be authorised to fail over when the primary is down. The safety property: each failover uses a new configuration epoch, so two Sentinels cannot promote two different replicas for the same epoch. That is why the count of Sentinels should be odd, and why they should not all live on the same hypervisor or in the same rack.

# sentinel.conf on three hosts
sentinel monitor mymaster 10.0.0.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster Str0ngPass

The quorum value is the number of Sentinels that must agree the primary is unreachable before a failover is attempted — not the number of Sentinels required to be alive. With three Sentinels and a quorum of two, you tolerate one Sentinel failure and still fail over; with a quorum of three you tolerate none.

Application clients must discover the current primary from Sentinel on each connection attempt, or go through a proxy that does it for them. A client hard-coded to the original primary IP will keep writing to a demoted replica after failover, which is how stale-read incidents start.

Cluster: slot ownership and client redirection

redis-cli --cluster create \
  10.0.0.21:6379 10.0.0.22:6379 10.0.0.23:6379 \
  10.0.0.24:6379 10.0.0.25:6379 10.0.0.26:6379 \
  --cluster-replicas 1

redis-cli --cluster check 10.0.0.21:6379
redis-cli -c -h 10.0.0.21 cluster info
redis-cli -c -h 10.0.0.21 cluster nodes

Cluster enforces a minimum of three primaries so that a majority of slot owners can always be reached. Resharding, slot migration and manual failover are all supported, but every one of them is an operational procedure that should be rehearsed. Clients must handle MOVED and ASK redirections; pipelined commands that touch many keys become slower because fewer of them can be batched, and transactions or Lua scripts that span slots fail outright.

Risks that apply to both

• Network partitions: in a partition, a minority side keeps serving reads and a majority side may promote a replica, so the same key can hold different values in two places. Correct application design (idempotent writes, TTLs, avoiding Redis as the sole system of record) mitigates this; no Redis topology eliminates it.
• Time: failover decisions depend on timeouts, and clock skew makes those decisions inconsistent. Run a disciplined time service as described in chrony NTP server configuration.
• Persistence on the old primary: a demoted primary that was unreachable can return with data the new primary never saw. Configure replicas to resync rather than continue serving.
• Observability: failover events are silent unless someone collects the logs. Ship Redis and Sentinel logs to a central pipeline like the one in Grafana Loki and Promtail and alert on +failover-state events.

The simplest decision rule: if the working set fits comfortably in one node's memory and you mostly need availability, use Sentinel. If you need the dataset to grow past one node, accept the multi-key restrictions and operational overhead, and use Cluster. That single question decides the answer in the overwhelming majority of deployments; everything else is tuning. Containerised workloads add one more consideration, since a failover that lands on a node under resource pressure just moves the outage — the checks in Kubernetes node NotReady troubleshooting are worth running before you attribute instability to the data layer.

原文链接：https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/