Not envy mandarin duck not envy fairy, a line of code half a day. Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

A few days ago, Antirez, the founder of Redis, announced on his personal blog that he would end his Redis tour!

Big God tired, Redis old, but Redis still very hot.

There are many Java clients for Redis, such as Jedis, Redisson, lettuce, etc.

So what is everybody using?

Today xJJDog did a little survey. Here are the results. localfile://media/15940259145555/15940262979977.jpg

You can see that Jedis has taken the top spot by a landslide.

Just a quick analysis.

jedis

localfile://media/15940259145555/15940301796032.jpg

Jedis and Redis differ by only one letter. I usually call it a cross between Redis and Java. It has the following characteristics:

  • Very lightweight, simple, very easy to retrofit and integration
  • Support stand-alone, sentinel, Cluster and other deployment modes, support transaction, pipeline, LUA script and so on. Fully functional.
  • It does not support read/write separation and needs to be implemented by itself
  • Using the BIO model, method calls are synchronous
  • Jedis client instances are not thread-safe and need to be used using connection pooling
  • Support connection pooling

Sample code.

Jedis jedis = null;
try {
  jedis = pool.getResource();
  / / /... do stuff here ... for example
  jedis.set("foo"."bar");
  String foobar = jedis.get("foo");
  jedis.zadd("sose".0."car"); jedis.zadd("sose".0."bike"); 
  Set<String> sose = jedis.zrange("sose".0, -1);
} finally {
  // You have to close jedis object. If you don't close then
  // it doesn't release back to pool and you can't get a new
  // resource from pool.
  if(jedis ! =null) { jedis.close(); }}/ / /... when closing your application:
pool.close();
Copy the code

redisson

localfile://media/15940259145555/15940302787489.jpg

I usually call it the son of Redis. As a son, some functions are not supported.

  • provideA distributed lockAnd implement distributed and extensible Java data structures, but does not support some basic Redis native features
  • Netty based implementation, using non-blocking IO, high performance. Support for asynchronous requests
  • Transactions are not supported and can be implemented using LUA scripts
  • Supports read/write separation in primary/secondary deployment and cluster deployment. On this basis, load balancing is supported for read operations
  • The API is thread-safe, and a single connection can perform multiple operations
  • Session sharing can be integrated with Spring Session
  • Support connection pooling
  • There is a Chinese document O__O

Sample code.

// 1. Create config object
Config config = new Config();
config.useClusterServers()
       // use "rediss://" for SSL connection
      .addNodeAddress("Redis: / / 127.0.0.1:7181");

// or read config from file
config = Config.fromYAML(new File("config-file.yaml")); 

// 2. Create Redisson instance

// Sync and Async API
RedissonClient redisson = Redisson.create(config);

// RxJava2 API
RedissonRxClient redissonRx = Redisson.createRx(config);

// 3. Get Redis based Map
RMap<MyKey, MyValue> map = redisson.getMap("myMap");

RMapReactive<MyKey, MyValue> mapReactive = redissonReactive.getMap("myMap");

RMapRx<MyKey, MyValue> mapRx = redissonRx.getMap("myMap");

// 4. Get Redis based Lock
RLock lock = redisson.getLock("myLock");

RLockReactive lockReactive = redissonReactive.getLock("myLock");

RLockRx lockRx = redissonRx.getLock("myLock");
Copy the code

Lettuce

Lettuce means, I think, totem, because I can’t recall any connection to Redis. localfile://media/15940259145555/15940301291245.jpg

  • In Netty’s event-driven communication layer, method calls are also asynchronous
  • No need to consider thread pools, high performance, Spring ecology default
  • The API is thread-safe, and a single connection can perform multiple operations
  • Connection pooling is also supported

Code cases.

RedisClient client = RedisClient.create("redis://localhost");
StatefulRedisConnection<String, String> connection = client.connect();
RedisStringCommands sync = connection.sync();
String value = sync.get("key");

////////////////////
StatefulRedisConnection<String, String> connection = client.connect();
RedisStringAsyncCommands<String, String> async = connection.async();
RedisFuture<String> set = async.set("key"."value")
RedisFuture<String> get = async.get("key")

async.awaitAll(set, get) == true

set.get() == "OK"
get.get() == "value"
Copy the code

Little analysis

Jedis supports the most primitive operations and can do anything, but its expressive semantics are limited. You might write a bunch of getSets, but you have to rely on comments to figure out what the code does. But it also has the benefit of being flexible enough to twist it to fit your needs. In addition, Jedis is also BIO, although BIO is generally slow, but Redis itself is fast, does not block for long, this is not a big problem in ordinary projects.

Redisson offers a more advanced package with a single function that allows the user to focus more on the business logic of heating and encapsulates a lot of wheels. Redisson not only provides a set of distributed Java common objects that are basically common to Java’s basic data structures, but also extends many distributed data structures, These include BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object Service, Scheduler Service). It’s Netty based, NIO supported and naturally faster. I still know about it through some of the advanced apis it implements, most notably its distributed lock, which can be used just like Java’s reentrant lock.

Lettuce stands for Lettuce and is now the default underlying implementation of Spring’s RedisTemplate. In contrast to jedis, which needs to create a physical connection for each instance to keep it thread-safe, lettuce is really good. It has high performance and supports asynchrony. Although the performance is high, but the programming model is more complex, not intuitive, many people do not like it.

For now, most projects still use BIO’s Jedis, which is fine. Jedis has a full range of features, an API that is easy to customize, and performance that meets demand. What’s more, it’s preconceived and has become standard for many people.

If you already meet your requirements in terms of functionality and performance, what’s the point of getting a new one? Is idle egg pain?

Ashamed sword cannot scabbard, proud sword does not return to the front? It doesn’t exist.

If you have this layer of Spring packaging that blocks these painful toggling operations, why not switch to a faster one?

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.