Você poderia usar o memcached, mas novamente todos acessariam seu servidor de banco de dados. No seu caso, você está dizendo que os resultados da consulta são tipo persistente portanto, pode fazer mais sentido armazenar em cache as respostas JSON do seu Web Service.
Isso pode ser feito usando um proxy reverso com um cache embutido. Acho que um exemplo pode ajudá-lo mais como fazemos isso com Jetty (Java) e NGINX:
Em nossa configuração, temos uma instância Jetty (Java) servindo uma API para nossos clientes móveis. A API está escutando em localhost:8080/api e retornando resultados JSON obtidos de algumas consultas em um banco de dados Mysql local.
Neste ponto, poderíamos servir a API diretamente para nossos clientes, mas aqui vem o proxy reverso:
Na frente da API fica um servidor web NGINX escutando de 0.0.0.0:80/ (em todos os lugares, porta 80) é cache. Se isso falhar, ele o busca em localhost:8080/api, o coloca em seu cache e serve o novo valor encontrado no cache.
Benefícios:
- Você pode usar outros recursos do NGINX:compactação GZIP automática dos arquivos JSON em cache
- Encerramento do endpoint SSL no NGINX.
- Os trabalhadores do NGINX podem beneficiá-lo, quando você tem muito mais conexões, todas solicitando dados do cache.
- Você pode consolidar seus endpoints de serviço
Pense na invalidação de cache:
Você tem que pensar em invalidação de cache. Você pode dizer ao NGINX para manter seu cache, digamos, por uma semana para todas as solicitações HTTP 200 para localhost:8080/api ou 1 minuto para todos os outros códigos de status HTTP. Mas se chegar o momento em que você deseja atualizar a API em menos de uma semana, o cache é inválido, então você precisa excluí-lo de alguma forma ou diminuir o tempo de cache para uma hora ou dia (para que a maioria das pessoas atinja o cache).
Isto é o que fazemos:Optamos por deletar o cache, quando está sujo. Temos outro JOB em execução no servidor ouvindo um evento de API de atualização acionado via Puppet. O JOB cuidará de limpar o cache do NGINX para nós.
Outra ideia seria adicionar a função de limpeza de cache dentro do seu Web Service. A razão pela qual decidimos contra esta solução é:O Web Service teria que saber que é executado por trás de um proxy reverso, o que quebra a separação de interesses. Mas eu diria que depende do que você está planejando.
Outra coisa, que tornaria seu Web Service mais certo seria servir cabeçalhos ETAG e cache-expires corretos com cada arquivo JSON. Novamente, não fizemos isso, porque temos um grande evento de atualização, em vez de pequenos para cada arquivo.
Notas laterais:
- Você não precisa usar o NGINX, mas é muito fácil de configurar
- NGINX e Apache têm suporte a SSL
- Há também o famoso Reverse Proxy (https://www.varnish-cache.org), mas que eu saiba ele não faz SSL (ainda?)
Então, se você fosse usar o Varnish na frente do seu Web Service + SSL, você usaria uma configuração como:NGINX -> Varnish -> Web Service.
Referências:- Servidor NGINX:http://nginx.com- Varnish Reverse Proxy:https://www.varnish-cache.org- Puppet IT Automation:https://puppetlabs.com- Tutorial de proxy reverso NGINX:http:/ /www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/ http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html
