Кэширование API REST, я должен использовать обратный прокси или memcache (d)?

Question

У меня есть REST API, где я хотел бы кэшировать JSON-ответ индекса (GET / foo) и действия чтения (GET / foo / 1), чтобы значительно повысить производительность. При наличии POST или PUT на ресурсе срок действия записей кэша для индекса и результатов чтения должен истекать, поэтому старый контент не обслуживается.

Это сценарий, который лучше всего делать с обратным прокси, таким как Squid / Varnish, или вы выбрали бы memcache (d)?

Answer 1

Использование обратного прокси, который находится на уровне HTTP, более прозрачный .Это означает, что можно видеть, что происходит по проводам.Плохо то, что немногие из них поддерживают кэширование аутентифицированных ответов , поэтому их эффективность может упасть до 0, если ваши ресурсы требуют аутентификации.Обратные прокси-серверы также обычно автоматически не истекают ресурс A (/foo), когда этот совершенно не связанный ресурс B (/foo/1) изменяется.Это правильное поведение, которое вы должны как-то добавить к своему решению.

Обе эти проблемы могут быть решены, если вы используете memcached, поскольку у него нет требования прозрачности.

Answer 2

Я бы пошел на лак с обратным прокси-сервером, потому что вы можете реализовать (и протестировать) свой сервис без использования логики кеширования и добавить кеширование в качестве отдельного слоя. Вы можете обновить / перезапустить службу, пока лак обслуживает старые результаты для запроса GET (отлично подходит для доступности), и легко настроить правила для лака, чтобы аннулировать (очистить) существующие результаты кэша на основе определенных действий GET / POST.

Answer 3

Если вы хотите использовать распределенную память, memcached - это хорошее решение.https://github.com/cpatni/middleman - обратный прокси, который использует memcached для кэширования.