Можете да използвате memcached, но отново всички биха ви ударили сървъра на базата данни. Във вашия случай казвате, че резултатите от заявката са някак постоянни така че може да има повече смисъл да кеширате JSON отговорите от вашата уеб услуга.
Това може да стане с помощта на Reverse Proxy с вграден кеш. Предполагам, че един пример може да ви помогне най-много как го правим с Jetty (Java) и NGINX:
В нашата настройка имаме Jetty (Java) екземпляр, обслужващ API за нашите мобилни клиенти. API слуша на localhost:8080/api и връща JSON резултати, извлечени от някои заявки в локална Mysql база данни.
В този момент бихме могли да обслужваме API директно на нашите клиенти, но тук идва обратното прокси:
Пред API се намира уеб сървър NGINX, който слуша от 0.0.0.0:80/ (навсякъде, порт 80) Когато мобилен клиент се свърже с 0.0.0.0:80/api, вграденият обратен прокси се опитва да извлече точния низ на заявка от това е кеш. Ако това не успее, той го извлича от localhost:8080/api, поставя го в своя кеш и обслужва новата стойност, намерена в кеша.
Предимства:
- Можете да използвате други екстри от NGINX:автоматично GZIP компресиране на кешираните JSON файлове
- Прекратяване на SSL крайна точка при NGINX.
- Служителите на NGINX може да са ви от полза, когато имате много повече връзки, всички изискващи данни от кеша.
- Можете да консолидирате крайните точки на услугата
Помислете за невалидиране на кеша:
Трябва да помислите за невалидиране на кеша. Можете да кажете на NGINX да задържи кеша си, да речем, за една седмица за всички HTTP 200 заявки за localhost:8080/api или 1 минута за всички останали HTTP кодове на състоянието. Но ако дойде моментът, в който искате да актуализирате API за по-малко от седмица, кешът е невалиден, така че трябва да го изтриете по някакъв начин или да намалите времето за кеширане до час или ден (така че повечето хора ще ударят кеш).
Ето какво правим:Избрахме да изтрием кеша, когато е мръсен. Имаме друго JOB, което се изпълнява на сървъра и слуша събитие за актуализиране на API задейства се чрез Puppet. JOB ще се погрижи за изчистването на кеша на NGINX вместо нас.
Друга идея би била да добавите функцията за изчистване на кеша във вашата уеб услуга. Причината, поради която се отказахме от това решение, е:Уеб услугата трябва да знае, че работи зад обратен прокси, което нарушава разделянето на проблемите. Но бих казал, че зависи от това, което планирате.
Друго нещо, което би направило вашата уеб услуга по-правилна би било да обслужва правилни заглавки на ETAG и cache-expires с всеки JSON файл. Отново не го направихме, защото имаме едно голямо събитие за актуализиране, вместо малки за всеки файл.
Странични бележки:
- Не е нужно да използвате NGINX, но е наистина лесен за конфигуриране
- NGINX и Apache имат поддръжка на SSL
- Има и известният обратен прокси (https://www.varnish-cache.org), но доколкото ми е известно, той не използва SSL (все още?)
Така че, ако трябваше да използвате Varnish пред вашата уеб услуга + SSL, ще използвате конфигурация като:NGINX -> Varnish -> уеб услуга.
Препратки:- NGINX сървър:http://nginx.com- Varnish Reverse Proxy:https://www.varnish-cache.org- Puppet IT Automation:https://puppetlabs.com- NGINX обратен прокси урок:http:/ /www.cyberciti.biz/faq/howto-linux-unix-setup-nginx-ssl-proxy/ http://www.cyberciti.biz/tips/using-nginx-as-reverse-proxy.html
