Каков наилучший способ кэширования XML-каналов локально?

Question

У меня есть фид XML, который содержит более 1000 записей о свойствах (аренда, продажа).

В настоящее время я называю этот фид 16x на домашней странице, всегда возвращая только 3 свойства по определенным критериям, например, 3 новых дома,3 новых квартиры и т. Д., 5 рекомендуемых квартир, 5 рекомендуемых квартир и т. Д.

Этот сценарий работал хорошо в течение 7 месяцев, в то время как было более 200 объектов недвижимости и только 100-200 просмотров в день.Сейчас я нахожусь на этапе, когда у меня более 700 посещений в день и более 1000 объектов недвижимости, и я загружаю 16 каналов отдельно, просто чтобы показать, что домашняя страница работает медленнее, а трафик становится все больше.

Поэтому я бы хотел кешироватьЭти потоки, я хотел бы, чтобы только мой «робот» напрямую загружал потоки из источника, а все посетители использовали мою локальную копию, чтобы сделать вещи намного быстрее и значительно снизить нагрузку на трафик.

У меня нет проблем с загрузкой XML локальнои локально вызывать файлы для отображения данных.Но я хотел бы знать, как решить возможные проблемы, такие как:

• не показывает данные клиентам, потому что робот обновляет файлы XML, а исходный файл будет перезаписан и пуст при загрузке новых данных
• использование файла XML в качестве локальной резервной копии означает, что если исходный сервер находится в автономном режиме, домашняя страница все еще будет работать и загружать
• , гарантируя, что я не заблокирую данные для клиентов таким образом, что робот не сможет обновить файлы

Моими первыми трудностями будет работа с 2 файлами xml для каждого потока: один будет показан клиентам, а другой будет загружен.Если загрузка правильная, то загруженный XML будет использоваться как оперативные данные, а другой будет удален.Некоторая инкрементная маркировка с одним файлом, работающим как файл, содержащий имя фактических данных.

Есть ли какой-нибудь способ, как кэшировать эти XML-файлы, чтобы он делал что-то подобное?На самом деле главная проблема заключается в наличии пуленепробиваемого решения, чтобы клиенты не видели страницы ошибок или пустые результаты.

Спасибо.

Answer 1

Используйте параметры кэширования, встроенные в HttpWebResponse. Это позволяет программно выбирать между прямым доступом к кешу (игнорируя свежесть), игнорируя кеш, принудительно обновляя кеш, заставляя кеш повторно проверяться, и нормальным поведением использования кеша, если он считается свежим, согласно возрасту исходного ответа информация, а также ее повторная проверка.

Даже если у вас действительно есть особые требования к кешированию, которые должны выходить за рамки этого, создайте его поверх правильного выполнения HTTP-кэширования, а не в качестве полной замены.

Если вам нужно управлять собственным кешем потоков XML, тогда нормальной блокировки файлов и, если действительно необходимо, .NET ReaderWriterLockSlims должно быть достаточно, чтобы разные потоки не мешали друг другу. Одной из возможностей устранения слишком высокого риска конфликта является использование по умолчанию прямого доступа в случае конфликта кэш-памяти. Учтите, что кэширование - это, в конечном счете, оптимизация (концептуально вы получаете файл «с сервера», кэширование просто делает это более эффективным способом). Следовательно, если вам не удалось быстро получить блокировку чтения, вы можете вернуться к загрузке напрямую. Это, в свою очередь, уменьшает ожидание, которое может произойти для блокировки записи (поскольку ожидающие блокировки не будут накапливаться со временем, пока запрашивается блокировка записи). На практике это, вероятно, произойдет не очень часто, но это избавит вас от риска неприемлемого разногласия, накапливающегося вокруг одного файла и повреждающего всю систему.

Answer 2

Я начну с предположения, что у вас нет собственного кода, создающего исходный XML-канал?Потому что если вы это сделаете, я бы посмотрел на добавление какой-то особой поддержки для запросов, которые вы хотите выполнить.

У меня была похожая проблема со сторонним фидом, и я создал задание, которое запускается несколько раз в день.загружает фид, анализирует его и сохраняет результаты локально в базе данных.

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

Затем я бы посмотрел на простой сервисный уровень для представления данных в вашем локальном хранилище.