la estabilidad JRedisFuture

Question

Estoy usando la aplicación sincrónica de JRedis, pero tengo la intención de cambiar a la forma asíncrona para comunicarse con el servidor Redis.

Pero antes de eso me gustaría pedir a la comunidad si la aplicación de JRedisFuture de alphazero jredis es estable suficiente para su uso en producción o no?

¿Hay alguien ahí fuera que lo está utilizando o tienen experiencia con ella?

Gracias!

Answer 1

Cuando JRedis recibe el apoyo para la semántica de transacción (Redis 1.3.n, JRedis rama principal) entonces, ciertamente, debe ser lo suficientemente "estable".

Redis protocolo de comandos no transaccionales, los propios atómicas, permite una ventana de error irrecuperable cuando se ha enviado un comando destructivo, y en la fase de lectura de los fallos de conexión. El cliente no tiene manera de saber si, de hecho, Redis procesa la última petición, pero la respuesta les caía debido a un fallo de red (por ejemplo). Incluso el cliente básico de petición / respuesta es susceptible a este (y creo que esto no se limita a Java, per se.)

Desde el protocolo del Redis no requiere ningún metadatos (en absoluto) con los comandos de tipo DML y DDL (por ejemplo no número Sist comando) se abre esta ventana de fracaso.

Con la canalización, ya no hay una asociación entre la secuencia de comandos que se está escribiendo y la respuesta que se está leyendo. (El tubo está enviando un comando que es N comandos detrás de la que causó Redis para la emisión de la respuesta que se lee al mismo tiempo Si algo va kaput, hay un montón de platos en el aire:.)

Dicho esto, cada objeto futuro en el tubo será marcado como falla y se le saber , precisamente, a la que respuesta se produjo el fallo.

¿Eso califica como "inestable"? En mi opinión, no. Esto es un problema con la canalización.

Una vez más, Redis 1.3.n con la semántica de transacción aborda completamente este problema.

Fuera de ese tema, con asíncronos (tuberías), hay una gran parte de la responsabilidad de su parte para asegurarse de que no excesivamente sobrecargado la entrada al conector. Para tuberías de un grado enorme JRedis le protegen de este (ya que el hilo de la persona que llama se utiliza para hacer así la escritura red de amortiguación natural de la carga de entrada en la cola de respuesta en espera).

Pero todavía se necesita para ejecutar las pruebas - que has dicho "Producción", ¿verdad? )) - y el tamaño de sus cajas y poner un límite en el número de hilos de carga en la parte delantera.

también recomendaría potencialmente no ejecutar más de una tubería JRedis en máquinas multi-núcleo. En la implementación existente (que no trozo del buffer de escritura) hay espacio para la eficiencia (en el contexto de la utilización de ancho de banda completo y el rendimiento maximizando) que se pueden obtener mediante la ejecución de varias tuberías al mismo servidor. Mientras que una tubería es ocupado creando memorias intermedias de escribir, la otra es la escritura, etc. Pero, estos dos tuberías interferirán entre sí debido a su (inevitable - recuerde que son colas y algún tipo de sincronización deben ocurrir) y la invalidación de caché periódica (en cada dequeue / enqueue en peor de los casos - pero en Doug Lea confiamos.) así que si la tubería Un promedio de latencia de golpe d1 (aisladamente), entonces también lo hace tubería B. Lamentablemente, corriendo dos de ellos en los mismos núcleos resultará en un período de invalidación amplia caché nuevo sistema que es la mitad del sistema original, de modo dos veces a medida que más se producen invalidaciones de caché (en promedio). Por lo que es contraproducente. Pero probar sus condiciones de carga, y en su plataforma de despliegue de producción proyectada.