Redis Cluster

Redis Cluster DCS instances use the native distributed implementation of Redis. Redis Cluster instances have the following features:

They are compatible with native Redis clusters.
They inherit the smart client design from Redis.
They deliver many times higher performance than master/standby instances.

Read/write splitting is supported by configuring the client for Redis Cluster instances. Read more about DCS's support for read/write splitting.

You cannot upgrade the Redis version for an instance. For example, a Redis Cluster DCS Redis 4.0 instance cannot be upgraded to a Redis Cluster DCS Redis 5.0 instance. If your service requires the features of higher Redis versions, create a Redis Cluster instance of a higher version and then migrate data from the old instance to the new one.
The method of connecting a client to a Redis Cluster instance is different from that of connecting a client to other types of instances. For details, see Connecting to Redis on a Client.

Architecture

The Redis Cluster instance type provided by DCS is compatible with the native Redis Cluster, which uses smart clients and a distributed architecture to perform sharding.

Table 1 lists the shard specifications for different instance specifications.

You can customize the shard size when creating a Redis Cluster instance. If the shard size is not customized, the default size is used. Size of a shard = Instance specification/Number of shards. For example, if a 48 GB instance has 6 shards, the size of each shard is 48 GB/6 = 8 GB.

**Table 1** Specifications of Redis Cluster DCS instances
Total Memory	Shards
4 GB/8 GB/16 GB/24 GB/32 GB	3
48 GB	6
64 GB	8
96 GB	12
128 GB	16
192 GB	24
256 GB	32
384 GB	48
512 GB	64
768 GB	96
1024 GB	128
2048 GB	128

Distributed architecture
Any node in a Redis Cluster can receive requests. Received requests are then redirected to the right node for processing. Each node consists of a subset of one master and one (by default) or multiple replicas. The master or replica roles are determined through an election algorithm.

Figure 1 Distributed architecture of Redis Cluster
Presharding
There are 16,384 hash slots in each Redis Cluster. The mapping between hash slots and Redis nodes is stored in Redis Servers. To compute what is the hash slot of a given key, simply take the CRC16 of the key modulo 16384.

Figure 2 Redis Cluster presharding
- Each shard of a Redis Cluster is a master/standby Redis instance. When the master node on a shard is faulty, the connections on the shard are interrupted in seconds, and the shard becomes unavailable. The standby node is automatically switched over within 15 to 30 seconds. The fault only affects the shard itself.
- For master node faults on a single shard, after a master/standby failover is complete, the previous faulty master node (then the standby one) of the shard will be recovered later. Service access to the previous master node of the shard will fail. In this case, configure Redis SDKs. For details, see Connecting to Redis on a Client.