Comparing DCS Redis Instance Types

Table 1 describes the differences between different Redis instance types in terms of features and commands.

**Table 1** Differences between DCS instance types
Item	Single-Node or Master/Standby	Redis Cluster
Redis version compatibility	Single-node and master/standby: Redis 4.0/5.0/6.0/7.0.	Redis 4.0/5.0/6.0/7.0 You can select a version when creating an instance.
Support	Keyspace notifications Pipelining	Keyspace notifications BRPOP, BLPOP, and BRPOPLPUSH commands Pub/Sub
Restrictions	Single-node instances do not support data persistence, backup, or restoration.	LUA script is restricted: All keys must be in the same hash slot. Hash tags are recommended. The client SDK must support Redis Cluster and be able to process MOVED errors. When you are using pipelining, MSET command, or MGET command, all keys must be in the same hash slot to avoid errors. Hash tags are recommended. When using keyspace notifications, establish connections with every Redis server and process events on each connection. When using a traversing or global command such as SCAN and KEYS, run the command on each Redis server.
Client	Any Redis client	Any client that supports the Redis Cluster protocol
Disabled commands	Command Compatibility lists disabled commands.	Command Compatibility lists disabled commands.
Replicas	A single-node instance has only one replica. By default, a master/standby instance has two replicas, with one of them being the master. When creating a master/standby DCS Redis instance, you can customize the number of replicas, with one of them being the master. Currently, the number of replicas cannot be customized for master/standby DCS Redis 3.0 instances.	By default, each shard in a cluster has two replicas. The number of replicas on each shard can be customized, with one of them being the master. When creating an instance, you can set the replica quantity to one, indicating that the instance only has the master node. In this case, high data reliability cannot be ensured.