Feature Comparison: Redisson vs Jedis
Two of the most popular Java client libraries for Redis are Redisson and Jedis. Redisson offers in-memory data grid features with support for a variety of distributed objects and services for Redis. Jedis, on the other hand, is a more lightweight offering that lacks certain features of other libraries.
If you're looking for a Java client library for Redis, you might wonder about the pros and cons of Redisson and Jedis. In this article, we'll compare and contrast the different features that both Redisson and Jedis have to offer.
|Map||plain commands only|
|Set||plain commands only|
|List||plain commands only|
|Queue||plain commands only|
|Deque||plain commands only|
|ScoredSortedSet||plain commands only|
|Stream||plain commands only|
Redisson has implementations of many different Java objects, including distributed collections. These Redisson objects help Java programmers use many of the familiar data structures that they are accustomed to in Java.
The list of distributed collections in Redisson includes:
Jedis, on the other hand, provides significantly less support for distributed collections in Redis.
The following objects are only supported with plain commands in Jedis:
Distributed locks and synchronizers
The question of locks and synchronization becomes much more complex when dealing with a distributed system, with different clients on separate machines.
Fortunately, Redisson supports some familiar Java locks and synchronizers for distributed computing, such as:
Jedis, however, does not include support for any of these locks and synchronizers in Redis. That means you'll have to handle this issue on your own, making the development process more complex.
|Object holder||plain commands only|
|AtomicLong||plain commands only|
|Publish/Subscribe||plain commands only|
|AtomicDouble||plain commands only|
|Geospatial||plain commands only|
|BitSet||plain commands only|
|HyperLogLog||plain commands only|
In addition to distributed collections, locks, and synchronizers, Redisson also implements a variety of other distributed objects in Java for Redis:
Of the distributed objects above, Jedis does not support the BloomFilter or BinaryStream objects at all. The other objects in the list are supported via plain commands only.
Advanced cache support
|Read-through strategy support|
|Write-through strategy support|
|Write-behind strategy support|
Only Redisson has a variety of advanced caching features. For example, Redisson includes support for three different caching strategies: read-through, write-through, and write-behind. Redisson also has a JCache API and a near cache that holds local copies of objects that are fetched from a remote cache. However, none of the features mentioned above are supported by Jedis out of the box.
|Reactive stream interface|
Redisson includes support for instances thread-safety, asynchronous interfaces, the Reactive Streams API, and the RxJava2 API. This support is entirely lacking in Jedis, however.
Redisson provides support for a variety of distributed services in Java:
Unfortunately, none of these distributed services are supported by Jedis.
Integration with frameworks
|Tomcat Session Manager|
Jedis includes support for the Spring Session and Spring Cache frameworks. In addition to these two frameworks, Redisson supports Hibernate Cache and the Tomcat Session Manager.
The good news is that both Jedis and Redisson include crucial security features such as authentication and SSL support.
Custom data serialization
|LZ4 compression codec|
|Snappy compression codec|
Redisson supports the Java Serialization API, as well as a variety of codecs:
- JDK Serialization
- LZ4 compression
- Snappy compression
Unfortunately, Jedis does not support JDK serialization or any of the above codecs.
Stability and ease of use
|Fully-managed services support
(AWS Elasticache, Azure Cache...)
|Large memory amount handling|
Both Redisson and Jedis are able to handle large amounts of memory. However, only Redisson includes support for fully managed services such as AWS Elasticache and Azure Cache.