Mógłbyś użyć memcached, ale znowu wszyscy trafiliby na twój serwer bazy danych. W twoim przypadku mówisz, że wyniki zapytania są trochę trwałe więc bardziej sensowne może być buforowanie odpowiedzi JSON z Twojej usługi sieciowej.
Można to zrobić za pomocą Reverse Proxy z wbudowaną pamięcią podręczną. Myślę, że przykład może pomóc ci najbardziej, jak to robimy z Jetty (Java) i NGINX:
W naszej konfiguracji mamy instancję Jetty (Java) obsługującą API dla naszych klientów mobilnych. API nasłuchuje na localhost:8080/api i zwraca wyniki JSON pobrane z niektórych zapytań w lokalnej bazie danych Mysql.
W tym momencie możemy obsługiwać interfejs API bezpośrednio naszym klientom, ale oto nadchodzi Reverse Proxy:
Przed API znajduje się serwer sieciowy NGINX nasłuchujący z 0.0.0.0:80/ (wszędzie, port 80).Kiedy klient mobilny łączy się z 0.0.0.0:80/api, wbudowany Reverse Proxy próbuje pobrać dokładny ciąg zapytania z to pamięć podręczna. Jeśli to się nie powiedzie, pobiera go z localhost:8080/api, umieszcza w swojej pamięci podręcznej i wyświetla nową wartość znalezioną w pamięci podręcznej.
Korzyści:
- Możesz użyć innych gadżetów NGINX:automatyczna kompresja GZIP buforowanych plików JSON
- Zakończenie punktu końcowego SSL w NGINX.
- Pracownicy NGINX mogą skorzystać, gdy masz dużo więcej połączeń, wszystkie żądają danych z pamięci podręcznej.
- Możesz skonsolidować swoje punkty końcowe usługi
Pomyśl o inwalidacji pamięci podręcznej:
Musisz pomyśleć o unieważnieniu pamięci podręcznej. Możesz powiedzieć NGINX, aby trzymał pamięć podręczną, powiedzmy, przez tydzień dla wszystkich żądań HTTP 200 dla localhost:8080/api lub 1 minutę dla wszystkich innych kodów stanu HTTP. Ale jeśli nadejdzie czas, w którym chcesz zaktualizować API za mniej niż tydzień, pamięć podręczna jest nieprawidłowa, więc musisz ją jakoś usunąć lub skrócić czas buforowania do godziny lub dnia (aby większość ludzi trafiła na Pamięć podręczna).
Oto, co robimy:zdecydowaliśmy się usunąć pamięć podręczną, gdy jest brudna. Mamy inne zadanie uruchomione na serwerze nasłuchujące zdarzenia Update-API wywołane przez Puppet. Zadanie zajmie się wyczyszczeniem pamięci podręcznej NGINX za nas.
Innym pomysłem byłoby dodanie funkcji czyszczenia pamięci podręcznej w usłudze sieci Web. Powodem, dla którego zrezygnowaliśmy z tego rozwiązania, jest to, że usługa sieciowa musiałaby wiedzieć, że działa za odwróconym serwerem proxy, co łamie separację obaw. Ale powiedziałbym, że to zależy od tego, co planujesz.
Kolejna rzecz, która sprawi, że Twoja usługa internetowa będzie bardziej właściwa byłoby dostarczanie poprawnych nagłówków ETAG i cache-expires z każdym plikiem JSON. Znowu tego nie zrobiliśmy, ponieważ mamy jedno duże zdarzenie aktualizacji zamiast małych dla każdego pliku.
Uwagi poboczne:
- Nie musisz używać NGINX, ale konfiguracja jest naprawdę łatwa
- NGINX i Apache obsługują SSL
- Istnieje również słynny Reverse Proxy (https://www.varnish-cache.org), ale według mojej wiedzy nie obsługuje SSL (jeszcze?)
Tak więc, jeśli miałbyś użyć lakieru przed usługą sieciową + SSL, użyj konfiguracji takiej jak:NGINX -> lakier -> Usługa sieciowa.
Referencje:- Serwer NGINX:http://nginx.com- Varnish Reverse Proxy:https://www.varnish-cache.org- Puppet IT Automation:https://puppetlabs.com- Samouczek NGINX reverse proxy:http:// /www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/ http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html
