Configuring Redis Clients

Redis clients can connect to any ScaleOut In-Memory Database server in a cluster on its server port (by default, port 721 for the open server port and port 724 for the secure server port) in a cluster using the standard RESP protocol. The server port and other configuration parameters are described in the section Configuration Parameters. A ScaleOut In-Memory Database cluster can contain one or more hosts, and each host runs one instance of the StateServer service process.

Note

This documentation uses the term host to denote a server within a cluster. Redis documentation uses the term node instead.

Secure client connections to a ScaleOut In-Memory Database cluster require that the self-signed certificate on each server be installed on each client as a trusted root certificate with certificate revocation checks disabled. The certificate’s public key can be found in the SOSS installation folder in the file soss_cert.pem. (See the section Installation for the location of the installation folder on Windows and Linux.) Note that each server uses a different certificate by default.

Once connected, Redis client libraries (for example, StackExchange.Redis for C# applications and Jedis for Java applications) typically obtain the mapping of hashslots to servers using either the CLUSTER SLOTS or CLUSTER NODES commands and then direct client access requests to the appropriate cluster host. (They are unaware that they are connecting to ScaleOut In-Memory Database instead of to an open-source Redis cluster.) This process occurs automatically and without any actions required by the client application. When using ScaleOut In-Memory Database, a client application does not need to create hashslots or a Redis database; these steps occur automatically. ScaleOut In-Memory Database supports one Redis database (the same as in open-source Redis clusters).

Note

Use the standard ScaleOut management tools to add and remove hosts from a cluster and to track cluster membership. Please see the section Management for a full description of the available management tools.

The following diagram shows a set of Redis clients connecting to a ScaleOut In-Memory Database cluster:

ScaleOut In-Memory Database automatically rebalances hashslots across cluster hosts during membership changes and after recovery from server or network failures. It also maintains replicas for all hashslots, promotes replica hashslots to primaries, and restores hashslot redundancy when it “self-heals” during recovery. The following diagram illustrates automatic migration of half of the hashslots (that is, 8K hashslots) after a second host is added to a single host cluster:

Once connected to a ScaleOut In-Memory Database cluster, Redis client libraries use the Redis cluster protocol to automatically track the movement of hashslots between hosts during load-balancing and after recovery from failures. If a hashslot has moved to a different host than expected by the client library during execution of a Redis command, the server will return a -MOVED error to the client library, which redirects the client to the correct host.

ScaleOut In-Memory Database stalls Redis commands while hashslots are in motion and returns -MOVED errors when the affected hashslots are ready to handle client requests at their destination hosts. This mechanism avoids exceptions from the client library that otherwise could occur during hashslot migration.

Note

You may need to lengthen the default connection timeout in the client library to avoid having the library prematurely close its connection during hashslot migration and throw an exception to the application. Hashslot migration can take several seconds, and the time depends on the size of the Redis database and the speed of the network.