Sie könnten memcached verwenden, aber wieder würde jeder Ihren Datenbankserver treffen. In Ihrem Fall sagen Sie, dass die Abfrageergebnisse art persistent sind Daher ist es möglicherweise sinnvoller, die JSON-Antworten Ihres Webdiensts zwischenzuspeichern.
Dies könnte mit einem Reverse Proxy mit eingebautem Cache erfolgen. Ich denke, ein Beispiel könnte Ihnen am meisten helfen, wie wir es mit Jetty (Java) und NGINX machen:
In unserem Setup haben wir eine Jetty (Java)-Instanz, die eine API für unsere mobilen Clients bereitstellt. Die API lauscht auf localhost:8080/api und gibt JSON-Ergebnisse zurück, die von einigen Abfragen in einer lokalen Mysql-Datenbank abgerufen wurden.
An dieser Stelle könnten wir die API unseren Kunden direkt bereitstellen, aber hier kommt der Reverse Proxy:
Vor der API sitzt ein NGINX-Webserver, der von 0.0.0.0:80/ (überall, Port 80) abhört. Wenn ein mobiler Client eine Verbindung zu 0.0.0.0:80/api herstellt, versucht der integrierte Reverse Proxy, die genaue Abfragezeichenfolge abzurufen es ist Cache. Wenn dies fehlschlägt, holt es es von localhost:8080/api, legt es in seinen Cache und liefert den neuen Wert, der im Cache gefunden wurde.
Vorteile:
- Sie können andere NGINX-Vorteile verwenden:automatische GZIP-Komprimierung der zwischengespeicherten JSON-Dateien
- SSL-Endpunkt-Beendigung bei NGINX.
- NGINX-Worker könnten Ihnen zugute kommen, wenn Sie viel mehr Verbindungen haben, die alle Daten aus dem Cache anfordern.
- Sie können Ihre Dienstendpunkte konsolidieren
Denken Sie an die Cache-Invalidierung:
Sie müssen über die Cache-Invalidierung nachdenken. Sie können NGINX anweisen, seinen Cache beispielsweise eine Woche lang für alle HTTP 200-Anforderungen für localhost:8080/api oder 1 Minute für alle anderen HTTP-Statuscodes zu speichern. Aber wenn die Zeit kommt, in der Sie die API in weniger als einer Woche aktualisieren möchten, ist der Cache ungültig, also müssen Sie ihn irgendwie löschen oder die Caching-Zeit auf eine Stunde oder einen Tag herunterdrehen (damit die meisten Leute die Zwischenspeicher).
Das machen wir:Wir haben uns entschieden, den Cache zu löschen, wenn er schmutzig ist. Auf dem Server läuft ein weiterer JOB, der auf ein Update-API-Ereignis lauscht über Puppet ausgelöst. Der JOB kümmert sich für uns darum, den NGINX-Cache zu löschen.
Eine andere Idee wäre, die Funktion zum Löschen des Caches in Ihren Webdienst einzufügen. Der Grund, warum wir uns gegen diese Lösung entschieden haben, ist:Der Webdienst müsste wissen, dass er hinter einem Reverse-Proxy läuft, was die Trennung von Bedenken bricht. Aber ich würde sagen, es hängt davon ab, was Sie vorhaben.
Eine andere Sache, die Ihren Webservice richtiger machen würde wäre es, mit jeder JSON-Datei korrekte ETAG- und Cache-Expire-Header bereitzustellen. Auch hier haben wir das nicht gemacht, weil wir für jede Datei ein großes Update-Event statt kleiner haben.
Randbemerkungen:
- Sie müssen NGINX nicht verwenden, aber es ist wirklich einfach zu konfigurieren
- NGINX und Apache unterstützen SSL
- Es gibt auch den berühmten Reverse Proxy (https://www.varnish-cache.org), der aber meines Wissens (noch?) kein SSL unterstützt
Wenn Sie also Varnish vor Ihrem Webdienst + SSL verwenden würden, würden Sie eine Konfiguration wie:NGINX -> Varnish -> Webdienst verwenden.
Referenzen:- 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
