Analysis of Jedis Client Access Modes and Implementation Details

This article provides a comprehensive analysis of the Jedis Java client for Redis, covering its three access modes—single‑node, sharding, and cluster—based on Jedis version 3.5.0.

Jedis supports single‑node mode via the Jedis class, sharding mode via ShardedJedis , and cluster mode via JedisCluster . The client can issue commands directly or through a Pipeline to improve throughput.

Single‑node mode : Create a Jedis object with host and port, then call Redis commands such as hmget . The underlying implementation uses BinaryJedis → Client → Connection .

public void main(String[] args) {
    Jedis jedis = new Jedis("localhost", 6379);
    jedis.hmget("foobar", "foo");
    jedis.close();
}

Sharding mode : Use ShardedJedis (or a ShardedJedisPool ) to distribute keys across multiple Redis nodes based on consistent hashing. The client builds a virtual‑node ring and maps each key to a node.

List
shards = new ArrayList<>(2);
shards.add(new JedisShardInfo(redis1));
shards.add(new JedisShardInfo(redis2));
ShardedJedis shardedJedis = new ShardedJedis(shards);
shardedJedis.set("a", "bar");

Cluster mode : From Redis 3.0 onward, the client can connect to a Redis cluster. JedisCluster discovers slots via the CLUSTER SLOTS command, builds a JedisSlotBasedConnectionHandler , and routes commands to the appropriate node.

Set
nodes = new HashSet<>();
nodes.add(new HostAndPort("127.0.0.1", 7001));
nodes.add(new HostAndPort("127.0.0.1", 7002));
JedisCluster cluster = new JedisCluster(nodes);
cluster.set("cluster-test", "my jedis cluster test");

The cluster implementation maintains a slot‑to‑node cache ( JedisClusterInfoCache ) and refreshes it on redirection or after failed attempts. Commands are executed through JedisClusterCommand , which handles retries and slot recalculation.

Pipeline : Jedis provides a Pipeline object to batch multiple commands without waiting for each reply. In single‑node mode, the pipeline sends all commands and later calls syncAndReturnAll() to retrieve the results. In cluster mode, keys must belong to the same hash slot for a pipeline to be effective; otherwise, a cluster‑aware pipeline must manage separate client connections per node.

Pipeline p = jedis.pipelined();
p.set("foo", "bar");
p.get("foo");
List
results = p.syncAndReturnAll();

Overall, the article explains the internal class hierarchy of Jedis (e.g., Jedis → BinaryJedis → Client → Connection ), the role of connection pools, and how the client implements consistent hashing, slot calculation (CRC16), and retry logic. Understanding these mechanisms helps developers choose the appropriate access mode and optimize Redis operations such as scaling or high‑throughput writes.