Советы по дизайну кэширования прокси - PullRequest
Новая
       13

Советы по дизайну кэширования прокси

2 голосов
/ 20 июля 2009

Я относительно новичок в прокси.
В настоящее время я должен разработать кеширующий прокси для работы.
У нас есть веб-сервис, который, естественно, обслуживает данные на основе обращений к ним.
Мне необходимо создать прокси-сервер для приложения с расширенными возможностями, которое кэширует результаты этих вызовов.
Результаты в основном представляют собой строковые названия продуктов, идентифицируемых по составу идентификаторов.

Я мог бы просто создать класс, который будет действовать как мой прокси-клиент, который кэширует результаты в кеше, я думал об использовании объекта System.Web.Caching.Cache.

Однако я подумал, что попрошу посмотреть, есть ли какие-то конструктивные аспекты и соображения, которые я пропустил. Есть ли общеизвестный дизайн, который я не нашел?

[ОБНОВЛЕНИЕ - 12 октября 2009]
Похоже, System.Web.Caching.Cache не рекомендуется для кэширования на стороне клиента.

http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx:

Класс Cache не предназначен для использовать вне приложений ASP.NET. Он был разработан и испытан для использования в ASP.NET для обеспечения кэширования для Web Приложения. В других типах приложения, такие как консоль приложения или Windows Forms приложения, кэширование ASP.NET может не работает правильно.

1 Ответ

0 голосов
/ 12 октября 2009

Во-первых, я использовал System.Web.Caching.Cache в решениях Winforms и Service, и у меня никогда не было с этим проблем. Я рекомендую принять меры против отказа от ответственности, выполнив тестирование, чтобы убедиться, что кэш работает и не теряет ресурсы, но ни одно из моих тестирований никогда не показывало, что это происходит.

В качестве альтернативы в Enterprise Library есть решение для кеширования, и, возможно, множество других с открытым исходным кодом, которые вы могли бы рассмотреть. И, возможно, есть и коммерчески поддерживаемые, если вы предпочитаете.

Однако, размещаете ли вы свой веб-сервис в ASP.Net (расширение .asmx обычно является хорошим индикатором). В этом случае вы все еще находитесь в ASP.Net и поэтому заявление об отказе от ответственности не должно применяться.

Также обратите внимание, что ASP.Net имеет опции кэширования, которые вы можете использовать непосредственно из web.config без необходимости какого-либо кодирования.

Но все вышеперечисленное относится к кешированию на стороне сервера.

Если ваша веб-служба использует HTTP (или HTTPS) в качестве транспортного уровня, то для кэширования прокси-сервера и клиента требуется использование заголовков ответа HTTP, я думаю, что задействованы Cache-Control, Expires и, возможно, Last-Modified. Затем клиент и прокси-серверы решают, будут ли они поддерживать кэширование или нет.

В качестве альтернативы, если вы действительно пытаетесь написать прокси-решение, которое поддерживает кэширование (и это будет переписывать колесо, поэтому у вас должна быть веская причина для этого), то вам, вероятно, нужен HTTP-обработчик с System.Web.HttpRequest. и System.Web.HttpResponse, представляющий клиентскую сторону, и передачу запроса на сервер с использованием System.Net.HttpWebRequest и System.Net.HttpResponse. Затем System.Web.Caching.Cache может поддерживать ваши кэшированные ответы на прокси-сервере. Тем не менее, здесь нужно будет реализовать много правил, включая заголовки HTTP-запросов (также есть опции Cache-Control).

...