Podrías usar memcached, pero de nuevo todos accederían a tu servidor de base de datos. En su caso, está diciendo que los resultados de la consulta son un poco persistentes por lo que podría tener más sentido almacenar en caché las respuestas JSON de su servicio web.
Esto se puede hacer usando un proxy inverso con un caché integrado. Supongo que un ejemplo podría ayudarte más sobre cómo lo hacemos con Jetty (Java) y NGINX:
En nuestra configuración, tenemos una instancia de Jetty (Java) que sirve una API para nuestros clientes móviles. La API escucha en localhost:8080/api y devuelve resultados JSON obtenidos de algunas consultas en una base de datos Mysql local.
En este punto, podríamos servir la API directamente a nuestros clientes, pero aquí viene el proxy inverso:
Delante de la API se encuentra un servidor web NGINX que escucha desde 0.0.0.0:80/ (en todas partes, puerto 80) Cuando un cliente móvil se conecta a 0.0.0.0:80/api, el proxy inverso integrado intenta obtener la cadena de consulta exacta de es caché. Si esto falla, lo obtiene de localhost:8080/api, lo coloca en su caché y entrega el nuevo valor encontrado en el caché.
Beneficios:
- Puede usar otras ventajas de NGINX:compresión GZIP automática de los archivos JSON almacenados en caché
- Terminación de extremo de SSL en NGINX.
- Los trabajadores de NGINX podrían beneficiarlo cuando tenga muchas más conexiones, todas solicitando datos del caché.
- Puede consolidar sus puntos finales de servicio
Piense en la invalidación de caché:
Tienes que pensar en la invalidación de caché. Puede decirle a NGINX que retenga su caché, digamos, durante una semana para todas las solicitudes HTTP 200 para localhost:8080/api, o 1 minuto para todos los demás códigos de estado HTTP. Pero si llega el momento en que desea actualizar la API en menos de una semana, el caché no es válido, por lo que debe eliminarlo de alguna manera o reducir el tiempo de almacenamiento en caché a una hora o un día (para que la mayoría de las personas presionen el cache).
Esto es lo que hacemos:Elegimos borrar el caché, cuando está sucio. Tenemos otro TRABAJO ejecutándose en el servidor escuchando un evento de actualización de API activado a través de Puppet. El TRABAJO se encargará de borrar el caché de NGINX por nosotros.
Otra idea sería agregar la función de borrado de caché dentro de su servicio web. La razón por la que decidimos no usar esta solución es:el servicio web tendría que saber que se ejecuta detrás de un proxy inverso, lo que rompe la separación de preocupaciones. Pero yo diría que depende de lo que estés planeando.
Otra cosa, que haría que su servicio web fuera más correcto sería servir los encabezados ETAG y cache-expires correctos con cada archivo JSON. Nuevamente, no hicimos eso, porque tenemos un evento de actualización grande, en lugar de pequeños para cada archivo.
Notas al margen:
- No tiene que usar NGINX, pero es muy fácil de configurar
- NGINX y Apache tienen soporte SSL
- También está el famoso Reverse Proxy (https://www.varnish-cache.org), pero que yo sepa, no funciona con SSL (¿todavía?)
Entonces, si usara Varnish frente a su servicio web + SSL, usaría una configuración como:NGINX -> Varnish -> Servicio web.
Referencias:- Servidor NGINX:http://nginx.com- Varnish Reverse Proxy:https://www.varnish-cache.org- Puppet IT Automation:https://puppetlabs.com- Tutorial de proxy inverso NGINX:http:/ /www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/ http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html
