Как кэшировать чтение базы данных в ролях Azure? - PullRequest
1 голос
/ 05 декабря 2011

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

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

Проблема в том, что мне делать с записями из нескольких экземпляров?Например, экземпляр 1 считывает данные и кэширует их, экземпляр 2 изменяет базу данных.Если экземпляр 1 не знает, что он должен перечитать базу данных, и фактически перечитывает базу данных, он работает с неверными данными.Я понятия не имею, как это легко сделать.

Есть ли простой способ сохранить согласованность кэшей разных экземпляров?

Ответы [ 3 ]

4 голосов
/ 05 декабря 2011

Именно здесь в игру вступает распределенное кэширование, и в Azure это обычно означает Кэширование Windows Azure AppFabric Windows

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

Хотя очевидно, что он не так эффективен, как кэширование внутри процесса, распределенное кэширование имеет несколько преимуществ -

  1. Это предотвращает множественные вызовы основного источника
  2. Из-за отсутствия кеша в процессе(и, фактически, на другом сервере) это уменьшило нагрузку на локальную память
  3. Клиенты извлекают выгоду из выборок друг друга - то есть, если один клиент вносит данные в кеш, настройки безопасности позволяют, у другого клиента теперь есть доступк этой информации, поэтому использование CACон может быть больше

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

Кроме того, будучи распределенной моделью, ферму кеша можно расширить для обслуживания множества запросов, хотя в Azure - поскольку кеш предлагается как услуга, об этом заботится не владелец, а платформа, а не владелец.одно из больших преимуществ информации PaaS и Windows Azure для кэша

1 голос
/ 06 декабря 2011

Если вы собираетесь использовать кэширование Azure AppFabric и хотите, чтобы данные были согласованными, вы можете отключить локальное кэширование.

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

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

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

1 голос
/ 05 декабря 2011

Вы можете использовать кэширование AppFabric, как сказал Йосси, но вы также можете использовать Memcached .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...