Vous pouvez utiliser memcached, mais encore une fois, tout le monde toucherait votre serveur de base de données. Dans votre cas, vous dites que les résultats de la requête sont plutôt persistants il peut donc être plus judicieux de mettre en cache les réponses JSON de votre service Web.
Cela pourrait être fait en utilisant un proxy inverse avec un cache intégré. Je suppose qu'un exemple pourrait vous aider le plus, comment nous le faisons avec Jetty (Java) et NGINX :
Dans notre configuration, nous avons une instance Jetty (Java) servant une API pour nos clients mobiles. L'API écoute sur localhost:8080/api et renvoie les résultats JSON extraits de certaines requêtes sur une base de données Mysql locale.
À ce stade, nous pourrions servir l'API directement à nos clients, mais voici le proxy inverse :
Devant l'API se trouve un serveur Web NGINX écoutant à partir de 0.0.0.0:80/ (partout, port 80) Lorsqu'un client mobile se connecte à 0.0.0.0:80/api, le proxy inverse intégré tente de récupérer la chaîne de requête exacte à partir de c'est du cache. Si cela échoue, il le récupère depuis localhost:8080/api, le place dans son cache et sert la nouvelle valeur trouvée dans le cache.
Avantages :
- Vous pouvez utiliser d'autres avantages NGINX :compression GZIP automatique des fichiers JSON mis en cache
- Résiliation du point de terminaison SSL sur NGINX.
- Les nœuds de calcul NGINX peuvent vous être utiles lorsque vous avez beaucoup plus de connexions, toutes demandant des données à partir du cache.
- Vous pouvez consolider vos points de terminaison de service
Pensez à l'invalidation du cache :
Vous devez penser à l'invalidation du cache. Vous pouvez dire à NGINX de conserver son cache, par exemple, pendant une semaine pour toutes les requêtes HTTP 200 pour localhost:8080/api, ou 1 minute pour tous les autres codes d'état HTTP. Mais s'il arrive le moment où vous souhaitez mettre à jour l'API en moins d'une semaine, le cache est invalide, vous devez donc le supprimer d'une manière ou d'une autre ou réduire le temps de mise en cache à une heure ou un jour (pour que la plupart des gens accèdent au cache).
Voici ce que nous faisons :Nous avons choisi de supprimer le cache, lorsqu'il est sale. Nous avons un autre JOB en cours d'exécution sur le serveur écoutant un événement Update-API déclenché via Puppet. Le JOB se chargera de vider le cache NGINX pour nous.
Une autre idée serait d'ajouter la fonction d'effacement du cache à l'intérieur de votre service Web. La raison pour laquelle nous avons décidé de ne pas utiliser cette solution est la suivante :le service Web devrait savoir qu'il fonctionne derrière un proxy inverse, ce qui rompt la séparation des préoccupations. Mais je dirais que cela dépend de ce que vous prévoyez.
Une autre chose, qui rendrait votre service Web plus correct serait de servir les en-têtes ETAG et cache-expires corrects avec chaque fichier JSON. Encore une fois, nous n'avons pas fait cela, car nous avons un grand événement de mise à jour, au lieu de petits événements pour chaque fichier.
Remarques :
- Vous n'êtes pas obligé d'utiliser NGINX, mais c'est vraiment facile à configurer
- NGINX et Apache prennent en charge SSL
- Il existe aussi le fameux Reverse Proxy (https://www.varnish-cache.org), mais à ma connaissance il ne fait pas (encore ?) SSL
Donc, si vous deviez utiliser Varnish devant votre Web Service + SSL, vous utiliseriez une configuration du type :NGINX -> Varnish -> Web Service.
Références :- Serveur NGINX :http://nginx.com- Varnish Reverse Proxy :https://www.varnish-cache.org- Puppet IT Automation :https://puppetlabs.com- NGINX reverse proxy tutorial :http:/ /www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/ http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html
