java - Redisson vs Jedis por redis

caching

Question

Ahora tengo que usar un cliente java para redis. Me he encontrado con Jedis y Redisson .

EDITAR : Replantear como la pregunta fue tipo de opinión basada.

¿Cuál es más eficiente en términos de velocidad? ¿Algún punto de referencia?

¿Cuál de ellos es capaz de proporcionar lo siguiente?

• Bloqueos distribuidos (y actualizar algunas claves en un mapa)

• Notificación automática de caducidad de clave, pero quiero que solo un suscriptor particular la reciba de entre un grupo de suscriptores (similar al concepto de grupo de consumidores en Apache Kafka). ¿Cómo se puede lograr esto?

PS: Por favor, no lo marque como duplicado de this .

Answer 1

Esa pregunta está basada en la opinión, pero vamos a incluir algunos puntos objetivos en ella:

TL; DR:

La elección del conductor depende de varias cosas:

• Dependencias adicionales
• Modelo de programacion
• Escalabilidad
• Ser opinado sobre la implementación de características de alto nivel.
• Perspectiva de tu proyecto, la dirección en la que quieres evolucionar.

Explicación

Dependencias adicionales

Algunos proyectos tienen opiniones sobre dependencias adicionales y dependencias transitorias al agregar una biblioteca.

Jedis es casi libre de dependencias, requiere Apache Commons Pool 2 para la agrupación de conexiones.

Redisson requiere Netty, la API de JCache y Project Reactor como dependencias básicas. Es extensible porque se integra con muchas otras bibliotecas (tienda Tomcat Session).

Modelo de programacion

Así es como interactúas con tu cliente de Redis. También define el nivel de abstracción.

Jedis es un controlador de bajo nivel que expone la API de Redis como llamadas de método Java:

Jedis jedis = …;
jedis.set("key", "value");
List<String> values = jedis.mget("key", "key2", "key3");

Redisson es un cliente de alto nivel que expone su funcionalidad a través de varios objetos API:

Redisson redisson = …
RMap map = redisson.getMap("my-map"); // implement java.util.Map
map.put("key", "value");
map.containsKey("key");
map.get("key");

Cada llamada invoca una o más llamadas de Redis, algunas de ellas se implementan con Lua (Redis "Scripting").

Escalabilidad

Hay varios controladores disponibles para Java que vienen con varias propiedades que pueden ajustarse a su proyecto. La escalabilidad juega con eso también. En cuanto a los controladores, se reduce el modo en que los controladores trabajan con sus recursos y qué modelos de programación admiten.

Jedis utiliza el bloqueo de E / S y las llamadas de método son sincrónicas. Se requiere que el flujo de su programa espere hasta que los sockets manejen la E / S. No hay soporte asíncrono ( Future , CompletableFuture ) o reactivo (RxJava Observable o Reactive Streams Publisher ).

Las instancias del cliente Jedis no son seguras para subprocesos, por lo que requieren agrupación de conexiones (instancia Jedis por subproceso de llamada).

Redisson utiliza E / S sin bloqueo y una capa de comunicación controlada por eventos con netty. Las llamadas a métodos son sincrónicas, asíncronas o reactivas (a través de Project Reactor 2.0 o 3.1). Las conexiones se agrupan, pero la API en sí misma es segura para subprocesos y requiere menos recursos. No estoy completamente seguro, pero quizás incluso puedas operar en una sola conexión. Esa es la forma más eficiente cuando se trabaja con Redis.

Opinión sobre la implementación del cliente.

Estos párrafos tratan sobre cómo se implementan los clientes.

Ambos clientes tienen una excelente cobertura de funciones, y puede cumplir sus requisitos con ambas bibliotecas.

Jedis es una implementación sencilla que simplemente escribe comandos en un OutputStream y analiza las respuestas. No mas que eso.

Si desea funciones de alto nivel, debe implementarlas utilizando la API de Redis. Te da control total sobre los comandos que invocas y el comportamiento resultante. La implementación de sus funciones puede requerir esfuerzos adicionales aquí.

Redisson es un cliente de alto nivel que proporciona funciones a través de sus abstracciones. Si bien puede usar estos objetos sin la necesidad de saber que están respaldados por Redis ( Map , List , Set , ...), cada llamada a la API se traduce en una o más llamadas Redis, algunas de ellas en la ejecución del script Lua.

Es posible que le guste o no la forma en que Redisson se comporta y cómo implementa las funciones, pero al final, no hay mucho que pueda hacer al respecto. El uso de las funciones de alto nivel de Redissons puede reducir sus esfuerzos de implementación.

panorama

Esa sección depende completamente de hacia dónde te diriges. Jedis admite todos los comandos de la API de Redis, Redis Standalone, Redis Sentinel y Redis Cluster. No hay lecturas de esclavos en configuraciones maestro-esclavo, pero supongo que eso es solo una cuestión de tiempo hasta que jedis proporcione estas características.

Con jedis, no puede ir asíncrono y el uso de las funciones avanzadas de AWS ElastiCache o las lecturas de esclavos requiere su propia implementación.

Redisson tiene una amplia cobertura de varias configuraciones. Admite todas las cosas que Jedis admite y proporciona estrategias de lectura para configuraciones Maestro / Esclavo, ha mejorado la compatibilidad con AWS ElastiCache.