Accepts large number of client connections on the netty4 side.
Funnels (multiplexes) all the commands towards Redis through a small Jedis threadpool.
Makes sense that we handle asynchronously (netty4) the potentially numerous clients.
It's just fine to handle synchronously (Jedis) a small number of persistent connections.
Of course, the blocking code does not block netty event loop. Jedis is always called from a separated thread pool.
This project makes extensive use of lambdas, so Java 8 is required.
- clone Sam Pullara's
redis-protocolproject (see credits)
- mvn -DskipTests install
- clone this repo
- mvn package
java -jar target/netty4-jedis-proxy-0.0.1.jar -cp target/lib/
-listenPort (-l) [Integer] Listen port (1234) -redisPort (-p) [Integer] Redis server port (6379) -redisHost (-h) [String] Redis server host (localhost) -jconnectTimeout (-t) [int] jedis connection timeout (2000) -jMinIdle (-n) [int] jedis minimum connection idle time (0) -jMaxIdle (-m) [int] jedis maximum connection idle time (8)
- This is still experimental, many commands are supported, but less frequently used commands may not yet be implemented.
- PubSub: handle with care, it uses one thread for each blocked connection. Redis-side connection is correctly released if client-side connection breaks.
- Port the rest of the non blocking commands to Jedis
- Port the rest of the blocking commands to Jedis (BLPOP, BRPOP, ... )