There is no one answer to your question because it depends.
Jedis and lettuce are both mature clients. To complete the list of Java clients, there is also Redisson, which adds another layer of abstraction (Collection/Queue/Lock/… interfaces instead of raw Redis commands).
It pretty much depends on how you’re working with the clients. In general, Jedis (java based client to connect to redis) is single-threaded in terms of data access, so the only benefit you gain by concurrency is offloading the protocol and I/O work to different threads. That is not fully true to lettuce and Redisson since they use netty under the hood (netty binds one socket channel to a particular event loop thread).
With Jedis, you can use only one connection only with one thread at a time. That correlates nicely with the Akka actor model because one actor instance is occupied only by one thread at a time.
On the other side, you need as much Jedis connections as threads that deal with a particular actor. If you start sharing Jedis connections across different actors, you either go for connection pooling, or you need to have a dedicated Jedis connection per actor instance. Please keep in mind that you need to take care of the reconnection (once a Redis connection is broken) by yourself.
With Redisson and lettuce, you get transparent reconnection if you wish to do so (That’s the default value to lettuce, not sure about Redisson).
By using lettuce and Redisson you can share one connection amongst all actors because they are thread-safe. You cannot share one lettuce connection in two cases:
- Blocking operations (since you would block all other users of the connection)
- Transactions (
MULTI/EXEC, since you would mix different operations with the transactions and that is certainly a thing you do not want to do so)
Jedis has no async interface, so you’re required to do this by yourself. That’s feasible, and I did something similar with MongoDB, offloading/decoupling the I/O part to other actors. You can use the approach from your code, but you’re not required to provide an own executor service because you do non-blocking operations in the runnable listener.
With lettuce 4.0 you’ll get Java 8 support (which is way better in terms of the async API because of the CompletionStage interface), and you can even use RxJava (reactive programming) to approach concurrency.
Lettuce is not opinionated on your concurrency model. It allows you to use it according to you needs, except the plain Future/ListenableFuture API of Java 6/7 and Guava is not very nice to use.
HTH, Mark