Du kunne bruge memcached, men igen ville alle ramme din databaseserver. I dit tilfælde siger du, at forespørgselsresultaterne er en slags vedvarende så det giver måske mere mening at cache JSON-svarene fra din webtjeneste.
Dette kunne gøres ved hjælp af en omvendt proxy med en indbygget cache. Jeg gætter på, at et eksempel måske kan hjælpe dig bedst, hvordan vi gør det med Jetty (Java) og NGINX:
I vores opsætning har vi en Jetty (Java) instans, der betjener en API til vores mobile klienter. API'et lytter på localhost:8080/api og returnerer JSON-resultater hentet fra nogle forespørgsler på en lokal Mysql-database.
På dette tidspunkt kunne vi betjene API direkte til vores kunder, men her kommer den omvendte proxy:
Foran API'et sidder en NGINX-webserver og lytter fra 0.0.0.0:80/ (overalt, port 80) Når en mobilklient opretter forbindelse til 0.0.0.0:80/api forsøger den indbyggede Reverse Proxy at hente den nøjagtige forespørgselsstreng fra det er cache. Hvis dette mislykkes, henter det det fra localhost:8080/api, lægger det i sin cache og serverer den nye værdi, der findes i cachen.
Fordele:
- Du kan bruge andre NGINX-godter:automatisk GZIP-komprimering af de cachelagrede JSON-filer
- SSL-slutpunktsafslutning ved NGINX.
- NGINX-medarbejdere kan være til gavn for dig, når du har mange flere forbindelser, og alle anmoder om data fra cachen.
- Du kan konsolidere dine serviceendepunkter
Tænk på cache-invalidering:
Du skal tænke på cache-invalidering. Du kan bede NGINX om at holde på sin cache, f.eks. i en uge for alle HTTP 200-anmodninger for localhost:8080/api, eller 1 minut for alle andre HTTP-statuskoder. Men hvis der kommer tidspunktet, hvor du vil opdatere API'et på under en uge, er cachen ugyldig, så du er nødt til at slette den på en eller anden måde eller skrue ned for cachetiden til en time eller dag (så de fleste vil ramme cache).
Dette er hvad vi gør:Vi valgte at slette cachen, når den er snavset. Vi har et andet JOB kørende på serveren og lytter til en Update-API begivenhed udløst via Puppet. JOBBET vil sørge for at rydde NGINX-cachen for os.
En anden idé ville være at tilføje funktionen til at rydde cache i din webtjeneste. Grunden til, at vi besluttede os for denne løsning, er:Webtjenesten skal vide, at den kører bag en omvendt proxy, som bryder adskillelsen af bekymringer. Men jeg vil sige, det afhænger af, hvad du planlægger.
En anden ting, som ville gøre din webservice mere rigtig ville være at tjene korrekte ETAG og cache-udløber headere med hver JSON-fil. Igen, det gjorde vi ikke, fordi vi har én stor opdateringsbegivenhed i stedet for små for hver fil.
Sidebemærkninger:
- Du behøver ikke bruge NGINX, men det er virkelig nemt at konfigurere
- NGINX og Apache har SSL-understøttelse
- Der er også den berømte Reverse Proxy (https://www.varnish-cache.org), men mig bekendt gør den ikke SSL (endnu?)
Så hvis du skulle bruge Varnish foran din Web Service + SSL, ville du bruge en konfiguration som:NGINX -> Varnish -> Web Service.
Referencer:- NGINX-server: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