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.
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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot