Tips on developing with Jedis

When developing Java client, Jedis or Lettuce is used. Among them, Jedis is a lightweight Redis java client. There are pros and cons for Jedis. (As of this writing, 3.0.0-m1 is the latest)

Pros

• Lightweight and faster than Lettuce
• API is easy and intuitive

Cons

• Supports Redis 2 and 3 (Redis 4 is not supported officially. But most api works for Redis 4 except new commands)
• Not updated frequently

Now, I’m showing you some tips on Jedis

For the starter

The main class to use is redis.clients.jedis.Jedis

import redis.client.jedis.Jedis;

Jedis client = new Jedis("127.0.0.1", 6379);
client.set("TestKey", "TestValue");
client.close();

For high traffic client, and standalone Redis

When Redis is a standalone process (no slave is used), then use redis.clients.jedis.JedisPool

import redis.clients.jedis.JedisPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import redis.client.jedis.Jedis;

GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
JedisPool clientPool = new JedisPool(poolConfig, "127.0.0.1", 6379);
Jedis client = clientPool.getResource();
client.set("TestKey", "TestValue");
clientPool.returnResource(client);
clientPool.close();

When using JedisPool, there are very important points.

• Adjust GenericObjectPoolConfig’s option (i.e. maxTotal, maxWaitMills) depending on client’s workload
• Don’t forget to call returnResource() (even in Exception). Without it, pooled object leak can occur)

For data sharding, with multiple Redis running, no slaves

When multiple Redis is running for data sharding, key based sharding is effective. In that case, use redis.clients.jedis.ShardedJedisPool

import redis.clients.jedis.ShardedJedisPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import redis.client.jedis.Jedis;
import redis.clients.jedis.JedisShardInfo;
import java.util.Arrays;

GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
JedisShardInfo shard1 = new JedisShardInfo("127.0.0.1", 6379);
JedisShardInfo shard2 = new JedisShardInfo("127.0.0.1", 6379);
JedisShardInfo shard3 = new JedisShardInfo("127.0.0.1", 6379);
ShardedJedisPool clientPool = new ShardedJedisPool(poolConfig, Arrays.asList(shard1, shard2, shard3));
Jedis client = clientPool.getResource();
client.set("TestKey", "TestValue");
clientPool.returnResource(client);
clientPool.close();

For single replication group with Sentinel

When a group of master-slave Redis with Sentinel is configured, use redis.clients.jedis.JedisSentinelPool

import redis.clients.jedis.JedisSentinelPool;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import redis.client.jedis.Jedis;
import redis.clients.jedis.JedisShardInfo;
import java.util.Set;
import java.util.HashSet;

Set sentinels = new HashSet();
HostAndPort sentinel1 = new HostAndPort("127.0.0.1", 5000);
HostAndPort sentinel2 = new HostAndPort("127.0.0.1", 5001);
HostAndPort sentinel3 = new HostAndPort("127.0.0.1", 5002);
sentinels.add(sentinel1.toString());
sentinels.add(sentinel2.toString());
sentinels.add(sentinel3.toString());
GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
JedisSentinelPool clientPool = new JedisSentinelPool("masterName", sentinels, poolConfig);
Jedis client = clientPool.getResource();
client.set("TestKey", "TestValue");
clientPool.returnResource(client);
clientPool.close();

Sentinel changes master node when a master is down. Therefore, client needs to reconnect to the new master when failover happens. By using JedisSentinelPool, failover is done automatically. But if other client is used, you must implement failover logic manually.

For multi master-slave groups with sharding

This architecture is recommended for mission critical system (Redis architecture for production) In that case, Sentinel client and sharding client are needed together. Unfortunatly, Jedis doesn’t support it. You need to extend Jedis to enable it. Refer to the following source code. (I put it on github because it’s too lengthy)

Advertisement