“SCS for Redis” support instances and clusters is created by the master-slave node, the main difference is in the supported capacity and the supported commands.

Property	Standard Edition	Cluster Edition
Feature	Compatible with “redis” native protocol	Restricted traversal, transaction, subscription and other related functions
Scope of application	The master-slave node instance is suitable for developers with small capacity and more use of “redis” functions.	The cluster is suitable for enterprise-level users with fast business growth and large business scale.
Version	Redis 4.0/3.2	Redis 3.2

Commands that are not supported by the master-slave instances

BGREWRITEAOF, BGSAVE, CLIENT GETNAME, CLIENT KILL, CLIENT LIST, CLIENT SETNAME, CONFIG GET, CONFIG RESETSTAT, CONFIG REWRITE, CONFIG SET, DEBUG OBJECT, DEBUG SEGFAULT, LASTSAVE, MONITOR, SAVE, SYNC, COMMAND, COMMAND COUNT, COMMAND GETKEYS, COMMAND INFO

Commands that are not supported by the clusters

Operations related to Key and string

KEYS, MIGRATE, MOVE, OBJECT, RANDOMKEY, RENAME, RENAMENX, SORT, SCAN

Operations related to Hash list

HSCAN

Operations related to Set

SSCAN

Pub/Sub

PSUBSCRIBE, PUBLISH, PUBSUB, PUNSUBSCRIBE, SUBSCRIBE, UNSUBSCRIBE

Transaction

DISCARD, EXEC, MULTI, UNWATCH, WATCH

Script

SCRIPT　EXISTS, SCRIPT　FLUSH, SCRIPT　KILL, SCRIPT　LOAD

List

BLPOP, BRPOP, BRPOPLPUSH

SortedSet

ZSCAN

HyperLogLog

PFADD, PFCOUNT, PFMERGE

Connection

ECHO, QUIT, SELECT

Server

BGREWRITEAOF, BGSAVE, CLIENT GETNAME, CLIENT KILL, CLIENT LIST, CLIENT SETNAME, CONFIG GET, CONFIG RESETSTAT, CONFIG REWRITE, CONFIG SET, DBSIZE, DEBUG OBJECT, DEBUG SEGFAULT, INFO, LASTSAVE, MONITOR, PSYNC, SAVE, SHUTDOWN, SLAVEOF, SLOWLOG, SYNC, and TIME

Precautions

The Redis clusters are hashed according to the key and different keys may be hashed to different nodes, i.e., different redises.

• For actions on multiple collections, it is required to ensure that the hashed nodes of these collections are at the same nodes, such as SUNION, SUNIONSTORE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SMOVE.
• For actions on multiple lists, it is required to ensure that the hashed nodes of these lists are at the same nodes, such as RPOPLPUSH.
• For actions on multiple ordered sets, it is required to ensure that the hashed nodes of these ordered sets are at the same nodes, such as ZUNIONSTORE.
• For script actions, it is required to ensure that the hashed nodes of multiple keys are on the same node, such as EVAL, EVALSHA.

If it is impossible to ensure that the hashed nodes of multiple keys are on the same node, they are sent by the backend to the node where the first key is located. Thus, it is impossible to find the key corresponding to other nodes, and guarantee the correctness of the final operation.