java - requerimientos - Arquitectura de servicios web: Redis(como caché) y PostgreSQL para la persistencia

redis rendimiento

Question

Estoy desarrollando una API REST de Java que usa datos de clientes de una base de datos postgreSQL.

Los números:. Cerca de 600 clientes al principio. Algunos de ellos hacen peticiones cada pocos segundos

Debido a que los clientes pagan por solicitud, necesitamos controlar si su número de solicitudes exitosas alcanza su límite, y al consultar datos postgresql (actualizar el valor del campo ''hitsCounter'') después de que cada solicitud es mala en términos de rendimiento, estamos pensando en implementar un sistema de caché con redis.

La idea: después de que un cliente hace su primera solicitud, recuperamos sus datos de postgresql y los almacenamos en caché redis. Luego, trabaje con estos datos de caché, por ejemplo, incrementando el valor de la clave ''hitsCounter'', hasta que el cliente deje de hacer solicitudes. Paralelamente, cada pocos minutos, un proceso en segundo plano persiste en los datos de la memoria caché redis a las tablas db, de modo que al final tenemos los datos actualizados en postgresql, y podemos tratarlos en el futuro.

Creo que obviamente aumenta el rendimiento, pero no estoy seguro de este "proceso de fondo". Una opción es verificar el TTL de los elementos de caché y si es menor que algún valor (significa que el cliente ha terminado de hacer solicitudes), persista los datos.

Me encantaría escuchar algunas opiniones sobre esto. ¿Es esta una buena idea? ¿Conoces algunas mejores alternativas?

Answer 1

Creo que su enfoque es una buena idea.

Personalmente, crearía un nuevo hilo que se ejecuta para siempre (while (true)) . Yo no haría dos hilos tú: el mismo hilo que cuenta las solicitudes almacena los datos en el db.

--Hilo

while (true)
 { 
   if (newHit)
   {
      hits++;
      //code..
      if (hits==30) //for example
        storeDatainDB(dataInCache); 
   }   
 }

Answer 2

Idea perfectamente razonable, pero no ha mencionado ninguna medida que haya realizado. ¿Cuál es el cuello de botella en su hardware objetivo con sus niveles de transacción objetivo? Sin saber eso, no puedes decirlo.

Puede usar una tabla no registrada tal vez. Solo inserte una fila con cada consulta, luego resuma cada 5 minutos, borrando los datos antiguos. Por otra parte, con las actualizaciones CALIENTES, y dicen 75% de factor de relleno, las actualizaciones tal vez sean más eficientes. No sé (y tú tampoco) que no lo hemos medido.

¿No es suficiente? Pegarlo en su propio tablespace en ssd.

¿No es suficiente? Pegarlo en su propia VM / máquina.

¿No es suficiente? Simplemente escriba las malditas cosas en archivos planos en cada cuadro de entrada y batch los datos una vez por minuto en la base de datos.

Además, ¿cuánto pagan por consulta? ¿Te importa si falla la energía y pierdes cinco segundos de registros de consulta? ¿Necesita poder reproducir los recibos de cada consulta con detalles de origen y una marca de tiempo?