Java Clients for Redis vs Memcached

Lettuce: the modern default

Lettuce is built on Netty and provides three API styles in one client: synchronous (for traditional blocking code), asynchronous (CompletionStage-based for futures-style concurrency), and reactive (Project Reactor Flux and Mono for backpressure-aware streaming). One Lettuce client instance is thread-safe and is intended to be shared across the entire application, with internal connection multiplexing.

Spring Boot's spring-boot-starter-data-redis depends on Lettuce by default since Spring Boot 2.0 (2018). Switching to Jedis requires an explicit dependency exclusion and adding the Jedis dependency. For most Spring Boot apps the default works well: you get sync Redis operations via RedisTemplate, async via ReactiveRedisTemplate (in the reactive Spring Web stack), and automatic connection management.

Cluster support is built in: RedisClusterClient.create(uris) gives you a cluster-aware client that handles topology discovery, MOVED redirections, and node failover automatically. Pub/sub is supported with dedicated connections (you do not subscribe on the shared command connection). Pipeline batching is supported via connection.setAutoFlushCommands(false) then explicit flush after batching.

Side-by-side: a rate limiter

@Service
public class RateLimiter {
  @Autowired
  private StringRedisTemplate redis;

  public boolean allow(String user, int limit, int winSec) {
    String key = "rl:" + user + ":" +
                  (System.currentTimeMillis()/1000/winSec);
    Long count = redis.opsForValue().increment(key);
    redis.expire(key, Duration.ofSeconds(winSec));
    return count <= limit;
  }
}

// Single bean, shared across all controllers.
// Lettuce multiplexes the underlying connection.

@Service
public class RateLimiter {
  private final MemcachedClient mc;

  public RateLimiter() throws IOException {
    mc = new MemcachedClient(
      new InetSocketAddress("localhost", 11211));
  }

  public boolean allow(String user, int limit, int winSec) {
    String key = "rl:" + user + ":" +
                  (System.currentTimeMillis()/1000/winSec);
    // Add first (races against another worker)
    mc.add(key, winSec, "0");
    long count = mc.incr(key, 1, 1L, winSec);
    return count <= limit;
  }
}

// Add+incr is two round trips per call.
// Race recoverable but fragile.

Jedis: the simpler choice

Jedis is the older Redis client for Java, now maintained by Redis Inc. It is intentionally simpler than Lettuce: a Jedis instance represents one connection, is not thread-safe, and is meant to be used either per-thread or pooled via JedisPool. The mental model is closer to JDBC connection pooling than to Lettuce's multiplexed-client model.

For applications with simple sync access patterns, Jedis can be easier to reason about: one connection, one operation, no surprises about which thread is handling the I/O. The downside is the connection pool maintenance and the inability to share a single client across many threads. For high-concurrency workloads Lettuce's multiplexing wins on both efficiency and operational simplicity.

Jedis remains the right choice when you specifically want explicit connection control (e.g. for transaction isolation requirements that don't match Lettuce's auto-flushing model), when you're working with older Spring Boot 1.x or non-Spring frameworks where Lettuce integration is less mature, or when you have existing Jedis-based code and the migration cost to Lettuce is not justified.

Redisson: distributed objects, Redlock, and more

Redisson is a different category of Redis client. Instead of exposing raw Redis commands, it provides distributed-Java-object abstractions: RMap<K,V> behaves like a ConcurrentHashMap but backed by Redis, RLock implements Java's Lock interface but the lock is distributed across all JVMs talking to the same Redis. Built-in support for Redlock multi-node distributed locking.

Redisson is the right choice when you want to use Redis as a coordination primitive without thinking about Redis commands. If your code path is "I want a distributed map" or "I want a leader election," Redisson hides the Redis-specific implementation and gives you a familiar Java API. The trade-off is some performance overhead and a learning curve for the Redisson-specific API; the gain is cleaner application code that does not have command-level Redis logic interleaved.

For pure Redis command access in performance-critical paths, drop down to Lettuce or Jedis. For high-level coordination (locks, leader election, counters, queues as Java objects), Redisson is faster to write and easier to maintain. Many production systems use both: Redisson for the distributed-primitives layer, Lettuce for the per-request raw cache operations.

FAQ

Related decisions