Jedis with NIO

[yangbodong22011]

Background

Jedis currently uses apache common-pool2 to manage connections. Users need to configure the three parameters maxTotal/maxIdle/minIdle to control the size of the connection pool. Since Redis is usually used as a cache to help reduce the burden on the database, it needs to bear very large concurrency, so When the business concurrency is greater than maxTotal, the error "Could not get a resource from the pool" will be encountered.

The current solution is that the user can increase the maxTotal parameter, but Redis usually only supports links below 10k, otherwise the performance will drop a lot. Assuming that the user has 100 machines, it is recommended that this parameter not exceed 100(10k/100=100), while the concurrency of the user may be much greater than 100. In addition, since JedisCluster will establish a pool for each node, this results in the excess number of connections on the user machine being maxTotal * cluster nodes number in cluster mode.

Therefore, it is necessary for us to introduce the NIO mode for Jedis to solve the problem of too many connections.

Existing plans

#647 and #713 have made some attempts, But it has not been merged. I have studied its related codes. I think there is still a certain gap between them and the production environment (especially in design). Compared with the advanced IO library, using the native NIO API is much more complicated. (But Jedis has always advocated simplicity and does not introduce too many dependencies).

New possible solutions

1. Introduce a mature NIO library, such as Netty (I prefer)
2. Continue to improve on #713.

Our achievements and goals

1. For stand-alone mode, we only consume one link; for cluster, each node only consumes one link (common commands, excluding pubsub and transaction)
2. Provide Jedis with an asynchronous API based on NIO.

Possible difficulties

1. The NIO mode requires careful handling of a single connection, such as this issue of Lettuce: Add support for disconnect on timeout to recover early from no RST packet failures lettuce#2082

Looking forward to getting more feedback from the community.

[sazzad16]

@yangbodong22011 First of all, thank you for this detailed conversation starter.

Secondly, if we are doing NIO, it should be a library like Netty.

I do think about this time to time but I wasn't sure about dropping IO socket completely. I was trying to support both which was making it too complex. My alternate idea was to introduce a new library, say jedis-nio, with mostly same code or with another jedis-base. (Just sharing my random thoughts.)

However, that's mostly before Jedis 4 where Connection class was a super class for Jedis class. Now that Connection is an object/resource, it could be easier. (Again, rambling my thoughts here.)

Anyways, I am all for the idea. The first key decision for us could be whether to support NIO as an option alongwith IO or to completely replace IO with NIO.

LBNL, do you plan to implement this?

[yangbodong22011]

The first key decision for us could be whether to support NIO as an option alongwith IO or to completely replace IO with NIO.

1. We cannot completely abandon IO socket, even if NIO is introduced. It is also impossible to directly replace JedisPool with NIO, because some users existing codes will monitor error codes, such as "Could not get a resource from the pool", if replaced, the monitoring will be invalid after the user upgrades Jedis.

2. Introduce NIO as a maven module of Jedis, coexist with IO socket, and share args, exception and other parts in the code. (I don't advocate that we create a new jedis-nio project, because it must ensure that there is no class conflict, and two communities need to be maintained, issue, pr, etc.).

LBNL, do you plan to implement this?

I would like to claim this task, but I think this is really a huge task and maybe I need help from the community.

I will update the detailed design document as soon as possible.

[sazzad16]

maybe I need help from the community.

Count me in!