Redisson vs Jedis for redis [closed]

Question

Now I have to use a java client for redis. I have come across Jedis and Redisson.

EDIT: Reframing as the question was kind of opinion based.

Which is more efficient in terms of speed? Any benchmarks?

Which of them is able to provide the following?

• Distributed locks(and update some keys in a map)

• Auto key expiry notification but I want this to be received by only one particular subscriber from among a group of subscribers(Similar to consumer group concept in Apache Kafka). How this can be achieved?

PS: Please don't mark it as duplicate of this.

Answer 1

That question is opinion-based but lets get some objective points into it:

TL; DR:

The driver choice depends on multiple things:

• Additional dependencies
• Programming model
• Scalability
• Being opinionated regarding the implementation of high-level features
• Prospect of your project, the direction in which you want to evolve

Explanation

Additional dependencies

Some projects are opinionated regarding additional dependencies and transient dependencies when adding a library.

Jedis is almost dependency-free, it requires Apache Commons Pool 2 for connection-pooling.

Redisson requires Netty, the JCache API and Project Reactor as basic dependencies. It's extensible because it integrates with a lot of other libraries (Tomcat Session store).

Programming model

That's how you interact with your Redis client. It also defines the abstraction level.

Jedis is a low-level driver exposing Redis API as Java method calls:

Jedis jedis = …;  jedis.set("key", "value");  List<String> values = jedis.mget("key", "key2", "key3"); 

Redisson is a high-level client that exposes its functionality through various API objects:

Redisson redisson = …  RMap map = redisson.getMap("my-map"); // implement java.util.Map  map.put("key", "value");  map.containsKey("key");  map.get("key"); 

Each call invokes one or more Redis calls, some of them are implemented with Lua (Redis "Scripting").

Scalability

There are multiple drivers available for Java that come with various properties that might fit your project. Scalability plays into that as well. Looking at drivers it boils down how drivers, work with their resources and which programming models they support.

Jedis uses blocking I/O and method calls are synchronous. Your program flow is required to wait until I/O is handled by the sockets. There's no asynchronous (Future, CompletableFuture) or reactive support (RxJava Observable or Reactive Streams Publisher).

Jedis client instances are not thread-safe hence they require connection-pooling (Jedis-instance per calling thread).

Redisson uses non-blocking I/O and an event-driven communication layer with netty. Method calls are synchronous, asynchronous or reactive (via Project Reactor 2.0 or 3.1). Connections are pooled, but the API itself is thread-safe and requires fewer resources. I'm not entirely sure, but maybe you can even operate on a single connection. That's the most efficient way when working with Redis.

Opinion about the client implementation

These paragraphs deal with how the clients are implemented.

Both clients have an excellent feature coverage, and you can fulfill your requirements with both libraries.

Jedis is a straightforward implementation that just writes commands to an OutputStream and parses the responses. No more than that.

If you want high-level features, then you need to implement these by using the Redis API. It gives you full control over the commands you invoke and the resulting behavior. Implementing your features might require additional efforts here.

Redisson is a high-level client that provides features through its abstractions. While you can use these objects without the need of knowing they are backed by Redis (Map, List, Set, …), each API call translates to one or more Redis calls, some to Lua script execution.

You might like or dislike the way Redisson behaves and how it implements the features, but in the end, there's not much you can do about it. Using Redissons high-level features might reduce your implementation efforts.

Outlook

That section entirely depends on where you're heading to. Jedis supports all Redis API commands, Redis Standalone, Redis Sentinel and Redis Cluster. There are no slave reads in master-slave setups, but I assume that's just a matter of time until jedis will provide these features.

With jedis, you can't go async and using advanced features of AWS ElastiCache or slave reads requires your own implementation.

Redisson has a broad coverage of various setups. It supports all the things Jedis supports and provides read strategies for Master/Slave setups, has improved support for AWS ElastiCache.