Potresti usare memcached, ma di nuovo tutti colpirebbero il tuo server di database. Nel tuo caso, stai dicendo che i risultati della query sono un po' persistenti quindi potrebbe avere più senso memorizzare nella cache le risposte JSON dal tuo servizio Web.
Questo potrebbe essere fatto utilizzando un proxy inverso con una cache integrata. Immagino che un esempio potrebbe aiutarti di più su come lo facciamo con Jetty (Java) e NGINX:
Nella nostra configurazione, abbiamo un'istanza Jetty (Java) che serve un'API per i nostri client mobili. L'API è in ascolto su localhost:8080/api e restituisce risultati JSON recuperati da alcune query su un database Mysql locale.
A questo punto, potremmo servire l'API direttamente ai nostri clienti, ma ecco che arriva il proxy inverso:
Davanti all'API si trova un server web NGINX in ascolto da 0.0.0.0:80/ (ovunque, porta 80) Quando un client mobile si connette a 0.0.0.0:80/api, il proxy inverso integrato tenta di recuperare la stringa di query esatta da è cache. Se non riesce, lo recupera da localhost:8080/api, lo inserisce nella sua cache e fornisce il nuovo valore trovato nella cache.
Vantaggi:
- Puoi utilizzare altri gadget NGINX:compressione GZIP automatica dei file JSON memorizzati nella cache
- Terminazione dell'endpoint SSL su NGINX.
- I lavoratori NGINX potrebbero avvantaggiarti, quando hai molte più connessioni, tutti richiedono dati dalla cache.
- Puoi consolidare i tuoi endpoint di servizio
Pensa all'invalidazione della cache:
Devi pensare all'invalidazione della cache. Puoi dire a NGINX di mantenere la sua cache, ad esempio, per una settimana per tutte le richieste HTTP 200 per localhost:8080/api o 1 minuto per tutti gli altri codici di stato HTTP. Ma se arriva il momento in cui vuoi aggiornare l'API in meno di una settimana, la cache non è valida, quindi devi eliminarla in qualche modo o ridurre il tempo di memorizzazione nella cache a un'ora o un giorno (in modo che la maggior parte delle persone colpisca il cache).
Questo è quello che facciamo:abbiamo scelto di eliminare la cache, quando è sporca. Abbiamo un altro JOB in esecuzione sul server in ascolto di un evento Update-API attivato tramite Puppet. Il JOB si occuperà di svuotare la cache di NGINX per noi.
Un'altra idea sarebbe quella di aggiungere la funzione di svuotamento della cache all'interno del servizio Web. Il motivo per cui abbiamo deciso di non utilizzare questa soluzione è:il servizio Web dovrebbe sapere che viene eseguito dietro un proxy inverso, che interrompe la separazione delle preoccupazioni. Ma direi che dipende da cosa stai pianificando.
Un'altra cosa, che renderebbe il tuo servizio web più giusto sarebbe servire le intestazioni ETAG e cache-expires corrette con ogni file JSON. Ancora una volta, non l'abbiamo fatto, perché abbiamo un grande evento di aggiornamento, invece di piccoli eventi per ogni file.
Note a margine:
- Non devi usare NGINX, ma è davvero facile da configurare
- NGINX e Apache hanno il supporto SSL
- C'è anche il famoso Reverse Proxy (https://www.varnish-cache.org), ma che io sappia non fa SSL (ancora?)
Quindi, se dovessi usare Varnish davanti al tuo Web Service + SSL, useresti una configurazione come:NGINX -> Varnish -> Web Service.
Riferimenti:- Server NGINX:http://nginx.com- Varnish Reverse Proxy:https://www.varnish-cache.org- Puppet IT Automation:https://puppetlabs.com- Tutorial 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
