Cluster Architecture

Redis Enterprise can be either a single Redis server database or a cluster. This allows a Redis Enterprise database to either scale horizontally across many servers through sharding or to copy data, which ensures high availability with Redis Enterprise replicas. Sharding is a type of database partitioning that separates large databases into smaller, faster, and more easily managed parts. These smaller parts are called data shards. With sharding or partitioning, you are not restricted to storing data on the memory of a single computer. Another advantage of sharding is being able to use the computational power of multiple cores.

In Redis Enterprise, a cluster is a set of cloud instances, virtual machine/container nodes, or bare-metal servers that let you create any number of Redis databases in a memory/storage pool that’s shared across the set. The cluster doesn’t need to scale up/out (or down/in) whenever a new database is created or deleted. A scaling operation is triggered only when one of the predefined limit thresholds has been reached, such as memory, CPU, network, and storage IOPS.

To create a sharded cluster, you need to first specify the number of shards. Once you’ve done this, your data will automatically be sharded or divided into groups and placed on optimal nodes.

At any given time, a Redis Enterprise cluster node can include between zero and a few hundred Redis databases in one of the following types:

• A simple database, i.e. a single primary shard
• A highly available (HA) database, i.e. a pair of primary and replica shards
• A clustered database, which contains multiple primary shards, each managing a subset of the dataset (or in Redis terms, a different range of “hash-slots”)
• An HA clustered database, i.e. multiple pairs of primary/replica shards