Кэширование в локальный экземпляр SQL на веб-сервере

Question

У меня очень высокий трафик (10 миллионов показов в день) / сайт с высокой доходностью, созданный с помощью .net. Основные метаданные хранятся на сервере SQL. У меня и моей команды есть уникальная стратегия кэширования, которая включает в себя регулярный запрос к базе данных новых метаданных с сервера среднего уровня, сериализацию данных в файлы и отправку их на веб-узлы. Веб-приложение использует данные в этих файлах (некоторые из них на самом деле являются сериализованными объектами) для создания экземпляров объектов и кэширует те в памяти, которые используются для запросов в реальном времени.

Преимущество этой модели в том, что она:

1. Позволяет веб-узлам кэшировать все данные в памяти и не выполнять никаких операций ввода-вывода при запросах к базе данных.
2. Если база данных когда-либо неожиданно выйдет из строя или из-за окон обслуживания, веб-серверы продолжат работу и будут приносить доход. Вы даже можете запустить веб-сервер без необходимости извлечения его начальных данных из БД, поскольку все необходимые данные находятся в файлах на его собственных дисках.
3. Позволяет нам полностью масштабироваться по горизонтали. Если пропускная способность страдает, мы можем просто добавить веб-сервер.

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

Одна стратегия, которую я рассматривал, заключается в использовании репликации для репликации нашей базы данных главного сервера sql на экземпляры локальной базы данных, установленные на каждом веб-сервере. Приложение веб-сервера будет использовать обычные методы sql / ORM для создания экземпляров объектов. Здесь мы все еще можем выдержать сбои основной базы данных, и нам не нужно было бы кодировать специализированный кеширующий код, а вместо этого можно было бы использовать nHibernate для обработки персистентности.

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

Answer 1

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

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

Во-вторых, внедрите зеркалирование базы данных для защиты от сбоя кластера. В зависимости от того, используете ли вы синхронное или асинхронное зеркалирование, ваш зеркальный сервер будет обновляться в режиме реального времени или на несколько минут позже. Если вы делаете это в режиме реального времени, вы можете автоматически переключаться на зеркало внутри своего приложения - SQL Server 2005 и выше поддерживает встраивание имени зеркального сервера в строку подключения, поэтому вам даже не нужно поднимать палец. Приложение просто подключается к любому серверу, работающему в режиме реального времени.

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

Моя любимая отправная точка для масштабирования - использование трех отдельных строк подключения в вашем приложении и выбор правильной в зависимости от потребностей вашего запроса:

• Realtime - указывает непосредственно на один главный сервер. Все записи идут в эту строку подключения, и только самые важные для чтения операции идут сюда.
• Почти в реальном времени - указывает на пул с балансировкой нагрузки доступных только для чтения SQL-серверов, которые обновляются при репликации или доставке журналов. В вашем оригинальном дизайне они жили на веб-серверах, но это опасная практика и кошмар обслуживания. SQL Server требуется много памяти (не говоря уже о деньгах на лицензирование), и вы не хотите быть привязанными к добавлению сервера базы данных для каждого веб-сервера.
• Отложенная отчетность. В вашей среде прямо сейчас она будет указывать на тот же пул абонентов с балансировкой нагрузки, но в будущем вы можете использовать такую ​​технологию, как доставка журналов, чтобы иметь пул серверов с отставанием на 8-24 часа. Они очень хорошо масштабируются, но данные далеко позади. Он отлично подходит для отчетов, поиска, долгосрочной истории и других потребностей, не связанных с реальным временем.

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

Answer 2

Рассматривали ли вы memcached ? Так как это:

1. в памяти
2. может работать локально
3. полностью масштабируемый по горизонтали
4. предотвращает необходимость повторного кэширования на каждом веб-сервере

Это может соответствовать всем требованиям. Проверьте Google для многих деталей и историй использования.

Answer 3

Мне кажется, что Windows Server AppFabric - это именно то, что вы ищете. (АКА "Скорость"). Из вводной документации :

Windows Server AppFabric предоставляет распределенное приложение в памяти кеш-платформа для разработки масштабируемый, доступный и высокопроизводительные приложения. AppFabric объединяет память в нескольких компьютеры, чтобы дать единый кеш просмотра приложений. Приложения могут хранить любые сериализуемый объект CLR без беспокоиться о том, куда попадает объект сохраняются. Масштабируемость может быть достигнута просто добавив больше компьютеров на потребность. Кэш также позволяет копии данных, которые будут храниться через кластер, тем самым защищая данные от неудачи. Это работает как услуга доступ по сети. В Кроме того, Windows Server AppFabric обеспечивает бесшовную интеграцию с ASP.NET, который включает сессию ASP.NET объекты для хранения в распределенный кеш без необходимости писать в базы данных. Это увеличивает производительность и масштабируемость приложений ASP.NET.

Answer 4

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

Создайте репликацию SNAPSHOT для основных таблиц, которые вы хотите кэшировать. Добавление новых объектов будет одинаково легко. На всех веб-серверах установите SQL Express и подпишитесь на эту публикацию. Поскольку это не часто изменяющиеся данные, вы можете быть уверены, что проблема с использованием ресурсов сервера минус сетевые поездки для основных данных.

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

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

Answer 5

Рассматривали ли вы использование SqlDependency кеширования?

Вы также можете записать данные на локальный диск на веб-уровне, если вас беспокоит начальное время запуска или простои БД. Но, по крайней мере, с SqlDependency вам не нужно опрашивать БД для поиска изменений. Его также можно сделать относительно прозрачным.

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

Если вы беспокоитесь о производительности и масштабируемости, вы можете рассмотреть возможность разделения уровня данных. Особенности зависят от вашего приложения, но, например, вы можете переместить данные только для чтения на пару серверов SQL Express, которые заполнены репликацией.

Если это поможет, я подробно об этом говорю в своей книге ( Сверхбыстрый ASP.NET ).