ReadFrom Settings

The ReadFrom setting describes how lettuce routes read operations to slave nodes.

By default, lettuce routes its read operations in multi-node connections to the master node. Reading from the master returns the most recent version of the data because write operations are issued to the single master node. Reading from masters guarantees strong consistency.

You can reduce latency or improve read throughput by distributing reads to slave members for applications that do not require fully up-to-date data.

Be careful if using other ReadFrom settings than MASTER. Settings other than MASTER may return stale data because the replication is asynchronous. Data in the slaves may not hold the most recent data.

Redis Cluster

Redis Cluster is a multi-node operated Redis setup that uses one or more master nodes and allows to setup slave nodes. Redis Cluster connections allow to set a ReadFrom setting on connection level. This setting applies for all read operations on this connection.

RedisClusterClient client = RedisClusterClient.create(RedisURI.create("host", 7379));
StatefulRedisClusterConnection<String, String> connection = client.connect();
connection.setReadFrom(ReadFrom.SLAVE);

RedisAdvancedClusterCommands<String, String> sync = connection.sync();
sync.set(key, "value");

sync.get(key); // slave read

connection.close();
client.shutdown();

Master/Slave connections

Redis nodes can be operated in a Master/Slave setup to achieve availability and performance. Master/Slave setups can be run either Standalone or managed using Redis Sentinel. Lettuce allows to use slave nodes for read operations by using the MasterSlave API that supports both Master/Slave setups:

Redis Standalone Master/Slave (no failover)
Redis Sentinel Master/Slave (Sentinel-managed failover)

The resulting connection uses in any case the primary connection-point to dispatch non-read operations.

Redis Sentinel

Master/Slave with Redis Sentinel is very similar to regular Redis Sentinel operations. When the master fails over, a slave is promoted by Redis Sentinel to the new master and the client obtains the new topology from Redis Sentinel.

Connections to Master/Slave require one or more Redis Sentinel connection points and a master name. The primary connection point is the Sentinel monitored master node.

Example

RedisURI sentinelUri = RedisURI.Builder.sentinel("sentinel-host", 26379, "master-name").build();
RedisClient client = RedisClient.create();

StatefulRedisMasterSlaveConnection<String, String> connection = MasterSlave.connect(
            client,
            new Utf8StringCodec(),
            sentinelUri);

connection.setReadFrom(ReadFrom.SLAVE);

connection.sync().get("key"); // Slave read

connection.close();
client.shutdown();

Redis Standalone

Master/Slave with Redis Standalone is very similar to regular Redis Standalone operations. A Redis Standalone Master/Slave setup is static and provides no built-in failover. Slaves are read from the Redis Master node’s INFO command.

Connecting to Redis Standalone Master/Slave nodes requires connections to use the Redis Master for the RedisURI. The node used within the RedisURI is the primary connection point.

RedisURI masterUri = RedisURI.Builder.redis("master-host", 6379).build();
RedisClient client = RedisClient.create();

StatefulRedisMasterSlaveConnection<String, String> connection = MasterSlave.connect(
            client,
            new Utf8StringCodec(),
            masterUri);

connection.setReadFrom(ReadFrom.SLAVE);

connection.sync().get("key"); // Slave read

connection.close();
client.shutdown();

Use Cases for non-master reads

The following use cases are common for using non-master read settings and encourage eventual consistency:

Providing local reads for geographically distributed applications. If you have Redis and application servers in multiple data centers, you may consider having a geographically distributed cluster. Using the NEAREST setting allows the client to read from the lowest-latency members, rather than always reading from the master node.
Maintaining availability during a failover. Use MASTER_PREFERRED if you want an application to read from the master by default, but to allow stale reads from slaves when the master node is unavailable. MASTER_PREFERRED allows a "read-only mode" for your application during a failover.
Increase read throughput by allowing stale reads If you want to increase your read throughput by adding additional slave nodes to your cluster Use SLAVE to read explicitly from slaves and reduce read load on the master node. Using slave reads can highly lead to stale reads.