Search code examples
javaredisamazon-elasticachelettuce

Lettuce: Shared connection for reactive API


I'm porting my current project from Jedis to Lettuce.

  1. Is it ok to use shared connection for reactive API? As long as I don't invoke blocking and transactional operations such as BLPOP and MULTI/EXEC?

  2. Should I use pooled connections for transactions through reactive API?

  3. Is it possible to pipeline commands through reactive API? Should I use dedicated connection for that?


Solution

  • Sharing one connection amongst multiple threads is the intended usage. There are multiple reasons:

    1. Connections are threadsafe.
    2. Redis is single-threaded. Using multiple connections to one host makes obviously no sense as there is no performance gain due to the lack of Redis processing parallelism.
    3. Connection pooling opens multiple connections. Although this might make sense for transaction and blocking command isolation, pooling may cause performance degradation. A single Redis server that receives connections from multiple application servers is kept busy in the first place with accepting and managing connections. The single-threaded Redis nature affects also the process of accepting and dropping connections.

    Regarding pipelining: lettuce does not await command completion before sending subsequent commands to Redis which means lettuce uses pipelining by default. The only way to prevent pipelining is outside synchronization on command invocation.

    Each command is flushed directly to the TCP connection. Lettuce can use batching to group commands before flushing them to the connection. Command flushing is a manual thing and more intended for bulk loading and not for reactive use.

    There are two more things:

    1. The wiki should answer your questions in a deeper level of detail: https://github.com/mp911de/lettuce/wiki
    2. Lettuce migrates away from RxJava 1 to a Reactive Streams API based on Project Reactor. That happens with lettuce 5.0 of which the first beta is already available.

    HTH,

    Mark